| ID | Title | Summary | Links | Status |
|---|---|---|---|---|
| AARC-G001 | Expressing group membership and role information | This document standardises the way group membership information is expressed Note: Superseded by AARC-G002 | Website | SUPERSEDED |
AARC-G002 | Guidelines on expressing group membership and role information | This document standardises the way group membership information is expressed. It defines a URN-based identification scheme that supports: indicating the entity that is authoritative for each piece of group membership information; expressing VO membership and role information; representing group hierarchies. | FINAL AEGIS | |
AARC-G021 | Guideline on the exchange of specific assurance information between Infrastructures | Infrastructures and generic e-Infrastructures compose an ‘effective’ assurance profile derived from several sources, yet it is desirable to exchange the resulting assurance assertion obtained between Infrastructures so that it need not be re-computed by a recipient Infrastructure or Infrastructure service provider. This document describes the assurance profiles recommended to be used by the Infrastructure AAI Proxies between infrastructures. | FINAL AEGIS | |
AARC-G025 | Guidelines for expressing affiliation | The goal of this document is to define how affiliation information should be expressed when transported across AARC BPA-compliant AAIs. Two different types of affiliation have been identified, namely Affiliation within the Home Organisation, such as a university, research institution or private company; and Affiliation within the Community, such as cross-organisation collaborations. Both affiliation types should be communicated to the service providers that rely on affiliation information in order to control access to resources. | FINAL AEGIS | |
| AARC-G026 | Guidelines for expressing community user identifiers | This document provides guidelines for expressing Community User Identifiers (CUIDs) such that the identifier values can be transported in an interoperable way across AARC Blueprint Architecture (BPA) compliant Authentication & Authorisation Infrastructures (AAIs). The CUID is a subject identifier, where the subjects are generally but not exclusively natural persons. The community user identifier is an attribute of the subject’s digital identity which is managed by the Community AAI. This Community Identity typically includes additional attributes such as profile information, group membership and role information. The guidelines specify how the CUID is communicated from the Community AAI to its connected services, i.e. infrastructure services (accessible through Infrastructure Proxies), generic and community services. This specification imposes requirements that must be implemented by the Community AAI and the Infrastructure Proxy. These requirements may serve as best practices for other services. | FINAL AEGIS | |
| AARC-G027 | Specification for expressing resource capabilities | This document provides a specification for expressing resource-specific capabilities using entitlements. A capability defines the resource or child-resource a user is allowed to access, optionally specifying certain actions the user is entitled to perform. Capabilities can be used to convey - in a compact form - authorisation information. | FINAL AEGIS | |
AARC-G031 | Guidelines for the evaluation and combination of the assurance of external identities | The Research Infrastructures (from now on just Infrastructures) that follow the AARC Blueprint Architecture [AARC-BPA] set up their own AAI to grant access to their services. The AAI is typically based on a central IdP-SP proxy that act as a gateway for the Infrastructure services and resources. In order to assign an identity to the users of the research collaboration or the community they serve, Infrastructures rely on external Identity Providers and employ identity linking strategies. The Infrastructures also define one or more assurance profiles, or a combination of assurance components, tailored to a specific risk assessment [AARC-G021]. In order to assign an assurance profile to a user, the Infrastructure shall evaluate the assurance components of the linked identity, or identities, used to register to the Infrastructure’s AAI or used during authentication at the infrastructure proxy. These guidelines provide a method to combine assurance information and to compensate for the lack of it. | FINAL AEGIS | |
| AARC-G045 | Evolution of the AARC Blueprint Architecture and best practices to support cross-infrastructure AAI interoperability | This document provides the first iteration of the AARC Blueprint Architecture (AARC-BPA-2018) including the "community-first" approach. | FINAL AEGIS | |
| AARC-G049 | A specification for IdP hinting | This document defines a generic browser-based protocol for conveying - to services - hints about the IdPs or IdP-SP-proxies that should be used for authenticating the principal. This protocol, colloquially referred to as Identity Provider (IdP) hinting, can greatly simplify the discovery process for the end-user, by either narrowing down the number of possible/IdPs to choose from or by making the actual selection process fully transparent. Note: Updated by AARC-G061 | UPDATED AEGIS | |
| AARC-G052 | OAuth 2.0 Proxied Token Introspection | This specification extends the OAuth 2.0 Token Introspection (RFC7662) method to allow conveying meta-information about a token from an Authorization Server (AS) to the protected resource even when there is no direct trust relationship between the protected resource and the token issuer. The method defined in this specification, termed "proxied" token introspection, requires access tokens to be presented in JWT format containing the iss claim for identifying the issuer of the token. Proxied token introspection assumes that the AS which is trusted by the protected resource has established a trust relationship with the AS which has issued the token that needs to be validated. | FINAL AEGIS | |
| AARC-G061 | A specification for IdP hinting | This document defines a generic browser-based protocol for conveying – to services – hints about the IdPs or SP-IdP-proxies that should be used for authenticating the principal. This protocol, colloquially referred to as Identity Provider (IdP) hinting, can greatly simplify the discovery process for the end-user, by enabling entities to produce and send hints that can be consumed by SP-IdP-proxies for routing the user to the correct upstream SP-IdP-Proxy or authenticating IdP. Note: Updates AARC-G049 | FINAL AEGIS | |
| AARC-G062 | A specification for hinting an IdP which discovery service to use | This document defines a generic browser-based protocol for conveying - to services - hints about the discovery service that should be used for letting the user choose an IdP. | FINAL AEGIS |
Overview
Content Tools
Tasks