...
- Alignment of user attributes: The attributes used to express user information should follow the REFEDS R&S attribute bundle, as defined in [REFEDS-R&S]
- Alignment of VO/group membership and role information: VO/group membership and role information, which is typically used by relying parties for authorisation purposes, should be expressed according to [AARC-G002]
- Alignment of resource capabilities information: Capabilities, which define the resources or child-resources a user is allowed to access, should be expressed according to [AARC-G027]
- Alignment of affiliation information: Affiliation information, including (i) the user’s affiliation within their Home Organisation, such as a university, research institution or private company, and (ii) affiliation within the Community, such as cross-organisation collaborations, should be expressed according to [AARC-G025]
- Alignment of assurance information: Assurance information used to express how much relying partins can trust the attribute assertions about the authenticating user should follow:
- REFEDS Assurance framework (RAF) [RAF-version-1.0]
- Guideline on the exchange of specific assurance information [AARC-G021]
- Guideline for evaluating the combined assurance of linked identities [AARC-G031]
- Guideline Expression of REFEDS RAF assurance components for identities derived from social media accounts [AARC-GO41]
- Guidelines for expressing the freshness of affiliation information, as defined in [AARC-G025]
- Oauth2 token validation across multiple domains: OAuth2 Authorisation Servers (AS) should be able to validate tokens issued by other trusted AS. Extending existing flows, such as the OAuth2 Token Exchange flow [OAuth2-Token-Exchange-draft], are being investigated for enabling the validation of such externally issued tokens.
- Workaround: Services need to connect to trust all AS that issue tokens, instead of relying on a single infrastructure proxy/AS . However, this integration should only be considered a short-term solution, given that connecting all end-services with all proxies/AS cannot scaleproxying multiple communities.
The table below lists the identified technical alignment activities and their status. A green checkmark indicates a complete activity, otherwise the expected time of implementation is provided.
| Activity | B2ACCESS | Check-in | eduTEAMS | INDIGO-IAM |
|---|---|---|---|---|
| Alignment of user attributes | ✓ | ✓ | ✓ | M21M24 |
| Alignment of VO/group membership and role information | ✓ | ✓ | ✓ | M21M24 |
| Alignment of resource capabilities information | M18 | ✓ | ✓ | M21M24 |
| Alignment of affiliation information | M24 | M24 | M24 | M24 |
| Alignment of assurance information (including freshness of affiliation information) | PY3 | PY3 | PY3 | PY3 |
| Oauth2 token validation across multiple domains (multi-proxy connection workaround) | ✓ | ✓ | ✓ | ✓ |
| Oauth2 token validation across multiple domains (initial implementation) | M24 | M24 | M24 | M24 |
| Oauth2 token validation across multiple domains | PY3 | PY3 | PY3 | PY3 |
...