|AARC-G001||Expressing group membership and role information|
This document standardises the way group membership information is expressed
Note: Superseded by 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.
|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.|
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.|
|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.|
|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.
|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.|
|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
|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