| Table of Contents |
|---|
Introduction
...
This page serves as a reference for the requirements gathered in DJRA1.1.
...
Requirements
2.1 (From: DJRA1.1 Section 5.1) Architectural and Technical Requirements:
ID | Requirement | Description | Type | Source |
|---|---|---|---|---|
| Architectural and Technical Requirements | ||||
| R1 | User and Service Provider friendliness | 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. | Usability | FIM4R, EGI, AARC Survey, GN4 Cloud Activity |
| R2 | Homeless users | 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 | Functional | FIM4R, TERENAa AAA, GN4-1 SA5 VOPaaS |
| R3 | Different levels of assurance | Description Credentials issued under different policies and procedures should include the provenance of the level under which they were issued | Functional | FIM4R, ELIXIR, EUDAT, EGI, AARC Survey, GN4-1 SA5 VOPaaS, GN3plus and GN4-1 SA5 Enabling Users |
| R4 | Community-based authorisation | The Federated AAI framework should enable communities to manage the assignment of attributes to their members for authorisation purposes | Functional | FIM4R, EUDAT, GN4-1 SA5 VOPaaS |
| R5 | Flexible and scalable attribute release policies | Flexible negotiation mechanisms are required to govern the release of identity attributes | Functional | FIM4R, EGI, AARC Survey |
| R6 | Attribute aggregation / Account linking | 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 | Functional | FIM4R, TERENA AAA, EUDAT, EGI, GN4-1 SA5 VOPaaS |
| R7 | Federation solutions based on open and standards-based technologies | Open and standards-based AAI technologies should be used by the different communities to allow for interoperability by means of suitable translation services | Implementation | FIM4R, TERENA AAA, EGI |
| R8 | Persistent user identifiers | The Federated AAI framework should reference the digital identities of users through long-lasting identifiers | Design | TERENA AAA, AARC survey, EGI, ELIXIR, GN4-1 SA5 VOPaaS |
| R9 | Unique user identities | Each user should have a single digital identity to allow SPs to uniquely identify their users | Design | AARC survey, EGI, ELIXIR, GN4-1 Cloud Activity |
| R10 | User-managed identity information Source | 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. | Usability | ELIXIR |
| R11 | Up-to-date identity information | The up-to-dateness of identity attributes should be guaranteed through an on-demand and/or recurring verification process | Reliability | ELIXIR |
| R12 | User groups and roles | The Federated AAI framework should support the assignment of groups to users, as well as the assignment of roles to users within their groups | Functional | ELIXIR, GN4-1 SA5 VOPaaS |
| R13 | Step-up authentication | 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 | Functional | ELIXIR |
| R14 | Browser & non-browser based federated access | The Federated AAI framework should provide federated access to both web-based and non-web-based services/applications | Functional | FIM4R, TERENA AAA, EGI, ELIXIR, GN3plus and GN4-1 SA5 Enabling Users |
| R15 | Delegation source | 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 | Functional | FIM4R, ELIXIR, EGI, AARC Survey |
| R16 | Social media identities | 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 | Interface | TERENA AAA, AARC survey, ELIXIR |
| R17 | Integration with e-Government infrastructures | The Federated AAI framework should support broader cross-domain collaboration including e-Government infrastructures | Interface | AARC survey, ELIXIR |
| R18 | Effective accounting | The Federated AAI framework should support effective accounting across distributed, heterogeneous data infrastructures | Functional | TERENA AAA, ELIXIR |
...
Policies and Best |
...
Practices | ||||
| RP1 | ||||
| Policy harmonisation |
...
| 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 |
...
...
| Supportability |
...
...
| ELIXIR, TERENA AAA, EUDAT, GN3plus and GN4-1 SA5 Enabling Users |
...
| RP2 |
Federated incident report handling |
...
A common procedure should be adopted for reporting security incidents that involve federations spreading across multiple administrative domains |
...
...
| Supportability |
...
...
| FIM4R, AARC survey |
...
| RP3 |
Sufficient attribute release |
...
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 |
...
...
| Supportability |
...
...
| FIM4R, AARC survey, EGI, GN4-1 Cloud Activity, GN3plusand GN4-1 SA5 Enabling Users |
...
| RP4 |
Awareness about R&E federations |
...
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 |
...
...
| Usability |
...
...
| FIM4R, AARC survey, EGI, GN4-1 Cloud Activity |
...
| , GN3plusand GN4-1 SA5 Enabling Users | |
| RP5 | Semantically harmonised identity attributes |
...
A common set of vocabularies should be used by the different communities to denote identity attributes managed by identity providers and attribute authorities |
...
...
| Supportability |
...
...
| FIM4R, EUDAT |
...
| RP6 | Simplified process for joining identity federations | The bureaucracy involved in joining identity federations should be reduced |
...
...
| Usability |
...
...
| AARC survey |
...
| RP7 | Best practises for terms and |
...
conditions | AARC could offer guidelines for describing the terms and conditions that service providers (operated in the R&E) should use |
...
...
| Serviceability/Supportability |
...
Source: EUDAT
3. Grouping
This is a try to group the above requirements by different parameters
...
| EUDAT |
Grouping by Type
Usability
- 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
Functional
- 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
Implementation
- R7 Federation solutions based on open and standards-based technologies
Design
- R8 Persistent user identifiers
- R9 Unique user identities
Reliability
- R11 Up-to-date identity information
Interface
- R16 Social media identities
- R17 Integration with e-Government infrastructures
Supportability
- 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
...
Grouping By Category
Guest Identities / Levels of Assurance
- R2 Homeless users
- R3 Different Levels of Assurance
- R13 Step-up authentication
- R16 Social media identities
- R17 Integration with e-Government infrastructures
User Identification
- R8 Persistent user identifiers
- R9 Unique user identities
- R10 User-managed identity information Source:
Attributes: Groups and Authorisation
- R4 Community-based authorisation
- R5 Flexible and scalable attribute release policies
- R12 User groups and roles
- R_P_5 Semantically harmonised identity attributes
Attributes: Release
- R6 Attribute aggregation / Account linking
- R_P_3 Sufficient attribute release
Technology requirements
- R7 Federation solutions based on open and standards-based technologies
- R14 Browser & non-browser based federated access
- R15 Delegation
Privacy, legal issues, and policies
- R10 User-managed identity information
- R11 Up to date identity information
- R18 Effective accounting
- R_P_1 Policy harmonisation
- R_P_2 Federated incident report handling
- R_P_7 Best practises for terms and conditions
Training
- 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