This page serves as a reference for the requirements gathered in DJRA1.1.
The Federated AAI framework should provide simple and intuitive tools that are able to address the needs of users with different levels of ICT literacy and enable more Service Providers (commercial and non-commercial) to connect.
Type: Usability
Source: FIM4R, EGI, AARC Survey, GN4 Cloud Activity
The Federated AAI framework should support users without a federated institutional IdP, such as citizen scientists and researchers without formal association to research laboratories or universities
Type: Functional
Source: FIM4R, TERENAa AAA, GN4-1 SA5 VOPaaS
Description Credentials issued under different policies and procedures should include the provenance of the level under which they were issued
Type: Functional
Source: FIM4R, ELIXIR, EUDAT, EGI, AARC Survey, GN4-1 SA5 VOPaaS, GN3plus and GN4-1 SA5 Enabling Users
The Federated AAI framework should enable communities to manage the assignment
of attributes to their members for authorisation purposes
Type: Functional
Source: FIM4R, EUDAT, GN4-1 SA5 VOPaaS
Flexible negotiation mechanisms are required to govern the release of identity attributes
Type: Functional
Source: FIM4R, EGI, AARC Survey
The Federated AAI framework should support the aggregation of identity attributes originating from different sources of authority, including federated IdPs and community-based attribute authorities
Type: Functional
Source: FIM4R, TERENA AAA, EUDAT, EGI, GN4-1 SA5 VOPaaS
Open and standards-based AAI technologies should be used by the different communities to allow for interoperability by means of suitable translation services
Type: Implementation
Source: FIM4R, TERENA AAA, EGI
The Federated AAI framework should reference the digital identities of users through long-lasting identifiers
Type: Design
Source: TERENA AAA, AARC survey, EGI, ELIXIR, GN4-1 SA5 VOPaaS
Each user should have a single digital identity to allow SPs to uniquely identify their users
Type: Design
Source: AARC survey, EGI, ELIXIR, GN4-1 Cloud Activity
A user should be able to self-manage some of their attributes, e.g., through a web- based UI. Depending on the attribute type, update restrictions should be imposed.
Type: Usability
Source: ELIXIR
The up-to-dateness of identity attributes should be guaranteed through an on-demand and/or recurring verification process
Type: Reliability
Source: ELIXIR
The Federated AAI framework should support the assignment of groups to users, as well as the assignment of roles to users within their groups
Type: Functional
Source: ELIXIR, GN4-1 SA5 VOPaaS
The Federated AAI framework should provide an additional factor or procedure that validates a user’s identity for high-risk transactions or according to policy rules
Type: Functional
Source: ELIXIR
The Federated AAI framework should provide federated access to both web-based and non-web-based services/applications
Type: Functional
Source: FIM4R, TERENA AAA, EGI, ELIXIR, GN3plus and GN4-1 SA5 Enabling Users
The Federated AAI framework should provide the capability for the users to delegate third parties, mostly computational tasks or services, to act on their behalf. This allows users to run thousands of actions in parallel without the need for interactive access, for example to save output data.
Type: Functional
Source: FIM4R, ELIXIR, EGI, AARC Survey
The Federated AAI framework should support common social media providers, such as Google and LinkedIn, but also the researcher ID providers, such as ORCID, to act as authentication providers and/or attribute authorities
Type: Interface
Source: TERENA AAA, AARC survey, ELIXIR
The Federated AAI framework should support broader cross-domain collaboration including e-Government infrastructures
Type: Interface
Source: AARC survey, ELIXIR
The Federated AAI framework should support effective accounting across distributed, heterogeneous data infrastructures
Type: Functional
Source: TERENA AAA, ELIXIR
All participating entities in the AAI ecosystem (IdPs, AAs, SPs) should commit to a common policy framework regarding the processing of personal data. This framework should incorporate at least the GÉANT Data protection Code of Conduct.
Type: Supportability
Source: ELIXIR, TERENA AAA, EUDAT, GN3plus and GN4-1 SA5 Enabling Users
A common procedure should be adopted for reporting security incidents that involve federations spreading across multiple administrative domains
Type: Supportability
Source: FIM4R, AARC survey
The set of attributes released to SPs should be extended, primarily, to allow consuming services to operate and, also, to allow for more advanced features, such as personalisation of services
Type: Supportability
Source: FIM4R, AARC survey, EGI, GN4-1 Cloud Activity, GN3plusand GN4-1 SA5 Enabling Users
The benefits offered by R&E federations should be promoted to all stakeholders, such as (commercial) service providers and identity providers that have not joined a federation yet
Type: Usability
Source: AARC survey, GN4-1 Cloud Activity
A common set of vocabularies should be used by the different communities to denote identity attributes managed by identity providers and attribute authorities
Type: Supportability
Source: FIM4R, EUDAT
Type: Usability
Source: AARC survey
AARC could offer guidelines for describing the terms and conditions that service providers (operated in the R&E) should use
Type: Serviceability/Supportability
Source: EUDAT
This is a try to group the above requirements by different parameters
R1 User and Service Provider friendliness
R10 User-managed identity information Source:
R_P_4 Awareness about R&E federations
R_P_6 Simplified process for joining identity federations The bureaucracy involved in joining identity federations should be reduced
R2 Homeless users
R3 Different Levels of Assurance
R4 Community-based authorisation
R5 Flexible and scalable attribute release policies
R6 Attribute aggregation / Account linking
R12 User groups and roles
R13 Step-up authentication
R14 Browser & non-browser based federated access
R15 Delegation Source:
R18 Effective accounting
R7 Federation solutions based on open and standards-based technologies
R8 Persistent user identifiers
R9 Unique user identities
R11 Up-to-date identity information
R16 Social media identities
R17 Integration with e-Government infrastructures
R_P_1 Policy harmonisation
R_P_2 Federated incident report handling
R_P_3 Sufficient attribute release
R_P_5 Semantically harmonised identity attributes
R_P_7 Best practises for terms and conditions
R2 Homeless users
R3 Different Levels of Assurance
R13 Step-up authentication
R16 Social media identities
R17 Integration with e-Government infrastructures
R8 Persistent user identifiers
R9 Unique user identities
R10 User-managed identity information Source:
R4 Community-based authorisation
R5 Flexible and scalable attribute release policies
R12 User groups and roles
R_P_5 Semantically harmonised identity attributes
R6 Attribute aggregation / Account linking
R_P_3 Sufficient attribute release
R7 Federation solutions based on open and standards-based technologies
R14 Browser & non-browser based federated access
R15 Delegation
R10 User-managed identity information Source:
R18 Effective accounting
R_P_1 Policy harmonisation
R_P_2 Federated incident report handling
R_P_7 Best practises for terms and conditions
R1 User and Service Provider friendliness
R_P_4 Awareness about R&E federations
R_P_6 Simplified process for joining identity federations The bureaucracy involved in joining identity federations should be reduced