| 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 identifier. |  | must be able to link SAML to X509 |
| 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. |  | ||
| 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. | | ||
| Service catalogue | Each research community should provide a service catalogue to help users find 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. | | TBC |
| 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. | | TBC | |
| 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 identified determinate period of time. | | TBC | |
| 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 fide 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 identifier, 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 find 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 flow 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 | Sirtfi adoption | To be acceptable to research communities, an IdP must meet the requirements of Sirtfi and assert this in metadata. | | |
| 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 Sirtfi is to require the definition 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 Snctfi addresses this with Proxied Research SPs. | | ||
| IdP suspension | Ability to disable all logins from identified 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. Snctfi requirement below is related. | | |
| Research communities voice | Representation of needs of research communities should be incorporated into eduGAIN governance with the ability to influence (inter)federation. Similar for REFEDS. | | ||
| Snctfi | Research communities should become Snctfi 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 Snctfi´d Proxy as meeting its R&S, Sirtfi, and CoCo obligations. | | This will be dependent on production policy implementation. In theory yes. | |
| .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 profiles to meet the evolving requirements of research communities. | | |
| 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 profile | Specify precisely what conditions IdPs must meet in order to provide federated credentials in research collaborations. Eg, Sirtfi + R&S. FIM4R to define the deployment profile and IdPs to adopt it. | | ||
| Federation entity attributes designed to enhance user experience should be populated | Eg, the entity attributes defined in the SAML “MDUI Information” specification 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 flow, even beforehand to set things up. Strong authentication (not necessarily MFA) may be required for some use cases. | | |
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-flow 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 scientific 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. | | |
| 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 specified 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.” | | Sustainability Statement received from EGI-Check-in |
Overview
Content Tools
Tasks