View Source

/

Category	Requirement	Explanation	Relevant?	Achived?
Identity lifecycle & linking	Account linking	The ability, for one entity, to link credentials from multiple IdPs to one account on an SP. More generically, the ability for a researcher to link multiple identities together, whether held in parallel or succession. The ability to accurately link accounts depends strongly upon the release of an appropriately unique and persistent identiﬁer.
Identity lifecycle & linking	ORCID	ORCIDs have become a common requirement. There are several ways by which they can arrive at Research SP: from the home organisation IdP, integrated by a proxy, user login at ORCID IdP, or provided manually by the researcher. The release of ORCIDs and their aggregation in community proxies should be prioritised.		It is planned to be achieved in the future.
Discovery & usability	Smart discovery	IdP discovery should be “smart enough” to quickly and easily take a user to their appropriate home IdP. For example show the user a short list tailored to them by home country, institute, e-Infrastructure, research community, project or other hints.
	Logo in metadata at an agreed standard size	Discovery services should display organisation logos to aid the user in choosing the IdP. IdPs or research community proxies should provide a logo at an agreed standard size.		It will be developed in one of the future projects.
	Service catalogue	Each research community should provide a service catalogue to help users ﬁnd relevant resources,i.e., service discovery.
AuthZ	Real time authorisation	AuthZ decisions at an SP must be based on identity credentials, attributes or assertions that have a short lifetime, i.e. they are valid now and not for too long into the future. Even within this short period it should be possible for the SP to look up real time status information, e.g. revocation lists and/or suspension lists.
	User blocking	It must be possible for an Infrastructure or research community to block access to a service based on the presence of an identity credential in an operational suspension list or revocation list.
	Service Provider quota management. Resource allocation + accounting, e.g. computer resources, access permissions	It must be possible for an SP operator to limit access of an individual identity or a group, or by attributes or roles allocated to the identity by the IdP or the research community AA/Proxy, to subject them to quotas and make resource allocations. Usage records (accounting) must be possible at the same granularity.
	Deprovisioning	Deprovisioning of AuthZ attributes, assertions, credentials, tokens, or other artifacts is an essential part of access life-cycle management. It must be possible to suspend or remove an individual’s access when they no longer possess right of access, e.g. because they have left the research community. Some use cases may require immediate removal of access while others may only require removal in an identiﬁed determinate period of time.
	Bona-Fide users for registered access	For controlled access (“registered” access) to a dataset or other resources, it must be possible to grant this only to those users who have been proven to have bona ﬁde rights to access.
	Group management	Research communities must be able to add individuals to Groups, for use in AuthZ, Quota management and Accounting. Groups should be hierarchical and users can belong to more than one group.
	Active role selection	Individual users must be able to select which attributes, groups or roles are “active” for a particular connection request and AuthZ decision.
Attribute release	Attribute release	IdPs must release a unique, persistent, omnidirectional identiﬁer, email address, and name for users when accessing research services. For example, ensure that the CoCo and R&S entity categories are widely adopted.
	Entity attribute adoption streamlining	Federations can take a long time to implement support for new entity tags and entity attributes, so in addition to federations implementing support for new entity attributes as soon as possible, the requirement is to ﬁnd a work around to that problem that enables dependent research activities to proceed pending Federations completing their implementation.
	Attribute release across borders	The R&S bundle, especially, needs to easily ﬂow from IdPs to SPs without regard to their nationalities. More outreach of the risk analyses performed by GEANT and REFEDS about R&S + CoCo entity categories is needed to increase adoption.
Security incident response	Sirtﬁ adoption	To be acceptable to research communities, an IdP must meet the requirements of Sirtﬁ and assert this in metadata.		If will be of interest in the future
	Peer assessment of incident response performance	Provide a way for participants in a federated security incident response to provide feedback on how well each participant has performed, as an incentive to maintain good operations-security processes.
	Incident response communication channels	Next step after Sirtﬁ is to require the deﬁnition and maintenance of IR communication channels. These channels should be tailored to the incident scenario, involving only necessary people, and the contact points should be periodically checked for responsiveness. Assume that Snctﬁ addresses this with Proxied Research SPs.
	IdP suspension	Ability to disable all logins from identiﬁed IdPs as part of managing a security incident. Can happen by home federation or by Proxy.
Research community proxies	IdP/SP Proxies must be allowed to join edugain	IdP/SP Proxies must be permitted to join eduGAIN or one of its constituent national federations. Snctﬁ requirement below is related.		to be implemented in the future.
	Research communities voice	Representation of needs of research communities should be incorporated into eduGAIN governance with the ability to inﬂuence (inter)federation. Similar for REFEDS.	has no been discussed
	Snctﬁ	Research communities should become Snctﬁ compliant for scalability and ease of management, enabling a Proxy to meet operational and policy obligations of both worlds that it interconnects: the research community and eduGAIN. Federations should accept a Snctﬁ´d Proxy as meeting its R&S, Sirtﬁ, and CoCo obligations.
	.int for R&E federation	Some research organisations have parts in multiple countries, making membership in one national R&E federation problematic. eduGAIN should provide a federation home for them.
Assurance & Multi Factor Authentication (MFA)	Assurance framework	The international community should continue work on developing assurance proﬁles to meet the evolving requirements of research communities.
Assurance & Multi Factor Authentication (MFA)	Step up Auth/MFA	Strong authentication, e.g. MFA, is required for some research community activities. The inclusion of MFA information in authentication tokens and metadata should be supported.
Interoperability	Avoid user/interop issues due to inconsistent propagation of metadata for entities.	Federations should support standard and automated metadata propagation processes and, where out of band actions are required, provide clear documentation and support
	IdP deployment proﬁle	Specify precisely what conditions IdPs must meet in order to provide federated credentials in research collaborations. Eg, Sirtﬁ + R&S. FIM4R to deﬁne the deployment proﬁle and IdPs to adopt it.
	Federation entity attributes designed to enhance user experience should be populated	Eg, the entity attributes deﬁned in the SAML “MDUI Information” speciﬁcation and errorURL should be populated at least.
Non web	Non-web use cases & support	A very important requirement for research communities. Many interactions between clients and servers are via the user’s command-line or via interacting applications using API access to AAI. Cannot assume that all access will be via a web browser interface, or that a web browser will be part of the authentication ﬂow, even beforehand to set things up. Strong authentication (not necessarily MFA) may be required for some use cases.		Interesting but not relevant right now
	Beyond ECP	One way of solving non-web access is via the use of SAML-ECP. Certain services currently depend on this, but other good means are available that should be used in preference. Hence, this requirement is to retool where ECP is currently present.
	Delegation	Delegation here means providing end-entities (users) ability to give a constrained portion of their access to another entity acting on their behalf. This might be reasonably accomplished either by impersonation or by proper delegation. This is required in any use case in which a work-ﬂow continues without the presence and direct connection of a user.
	Credential translation	Services will not always be able to consume the credentials the user currently has. Translations from one type of credential to another is a very common and important requirement.
On-boarding & support	Non-legal entity participation in eduGAIN	Research communities are often not legal entities. This causes problems should they wish to join R&E federations and hence eduGAIN. One institute does not wish to take on liability for the actions of others in the community.
	eduGAIN test/dev environment	Easy-to-use testing environments to allow new Proxies and new SPs to experiment with their Federationfacing parts without interfering with existing production deployments.
	Proxy test/dev environment	Easy-to-use testing environments to allow new Proxies to experiment with their SP-facing parts and new SPs to experiment with their Proxyfacing parts without interfering with existing production deployments.
	Simple process for scientiﬁc SPs to become relying parties	Develop guidance and corresponding on-boarding process to address questions such as: How does a new research SP become a relying party? And an RP of what? Relying parties through a Federation, or behind a proxy?
	Help Desk	Federations and eduGAIN should provide a Help Desk capability suited to supporting interactions between federations and research communities.
Sustaining critical infrastructure	IdP of Last Resort	Provide sustained services to meet the many cases where global researchers do not have access to an acceptable Home Organization IdP, as an alternative to each research community solving this problem for itself.		Not considered for implementation in the pilot but foreseen as important for EPOS community
	IdPoLR not-a-robot	Google-based captcha is not available to some users in China, so another approach to not-a-robot must be determined.
	Sustainable operation of speciﬁed critical services	When a “component” service ,i.e. one that is integrated with others to produce a valuable result, e.g. CILogon, becomes established as a critical element of federated e-Infrastructure, research communities look to Federations to ensure sustainable operations.”