Building an AARC-compliant AAI is achieved through the principles of the AARC Blueprint Architecture (BPA) and by following the guidelines formally approved by AEGIS. These guidelines provide the reference set for achieving interoperability across infrastructures. AEGIS approval ensures that specifications have been reviewed for operational feasibility and community consensus, making them key enablers of interoperability for research collaboration. The following requirements are presented thematically, reflecting the main technical functions needed to support interoperability.

Harmonised Identity Representation

Guidelines in this group define how identity attributes are expressed in a consistent way. By harmonising subject identifiers, affiliation information, group membership, and assurance, they ensure that users can be reliably recognised and their attributes correctly interpreted by different infrastructures.

AARC-G026 – Community User Identifiers

Defines globally unique, persistent, and opaque identifiers for users.

• Expressed as:
• OIDC claim: voperson_id claim (in ID token and UserInfo endpoint)
• SAML attribute: voPersonID
• Identifiers must not be reassigned and should be permanent where possible

AARC-G025 – Affiliation Information

Specifies how to express the user’s affiliation within their Home Organisation, such as a university or research institution.

• Affiliation is typically based on the eduPersonScopedAffiliation attribute released by the user’s Home Organisation
• Expressed as:
• OIDC claim: voperson_external_affiliation
• SAML attribute: voPersonExternalAffiliation
• Includes freshness requirements expressed through eduPersonAssurance

AARC-G057 – Inferring Origin Affiliation

Provides rules for constructing voPersonExternalAffiliation when not directly asserted by the user’s Home Organisation.

• Inference may use eduPersonAffiliation, metadata, or community registries
• If no reliable inference can be made, the affiliation value must be set to unknown@<issuer>. This guarantees that the voPersonExternalAffiliation SAML attribute or voperson_external_affiliation OIDC claim is always present for downstream services.

AARC-G069 – Group Membership and Roles

Defines a URN-based syntax for expressing groups, subgroups, and roles.

• Example: urn:example.org:group:team:subteam:role=member
• Expressed as:
• OIDC claim: entitlements (RFC 9068)
• SAML attribute: eduPersonEntitlement
• Supports implied membership (subgroup ⇒ parent group)
• Provides encoding and normalisation rules to avoid clashes across collaborations

AARC-G021 – Assurance

Specifies how Proxies express identity assurance information.

• Uses REFEDS RAF profiles (Cappuccino, Espresso) and supplementary IGTF profiles (BIRCH, DOGWOOD).
• Introduces the AARC-Assam profile for identities partially based on social IdPs, with compensatory proxy controls.

Assurance expressed as:

• OIDC claim: eduperson_assurance
• SAML attribute: eduPersonAssurance

AARC-G031 – Combining Assurance

Provides methods for proxies to evaluate assurance when linking identities.

• Uses REFEDS Assurance (RAF) components: Identifier uniqueness (ID), Identity Proofing (IAP), Attribute Freshness (ATP)
• Defines compensatory controls (e.g. email verification, Research & Scholarship entity category) when values are missing.

AARC-G056 – Attribute Profile (in development)

Defines a harmonised AARC attribute profile consolidating subject identifiers, names, email, affiliation, assurance, groups memberships and roles, and resource capabilities. Once approved, it will provide a single reference profile for attribute release across AARC-compliant infrastructures.

Authorisation and Access Control

Authorisation can rely on identity attributes such as group membership and roles, affiliations, and assurance (described in the identity representation guidelines). Alternatively, it can be based on community- or service-defined capabilities. For token-based workflows, this information may be included directly in the token (e.g. as claims or scopes) or retrieved indirectly via token introspection. The guidelines in this group provide mechanisms to represent resource capabilities and to validate tokens in multi-proxy environments.

AARC-G027 – Resource Capabilities

Introduces a URN syntax for representing what actions a user can perform on a resource.

• Format: <NAMESPACE>:res:<RESOURCE>[:act:<ACTION>[,<ACTION>]...]#<AUTHORITY>
• Supports hierarchical resource structures and explicit action scopes, enabling fine-grained, interoperable expression of access rights.

AARC-G052 – Proxied Token Introspection (under final consultation)

Extends OAuth 2.0 Token Introspection (RFC 7662) to multi-proxy environments.

• Allows an OAuth 2.0 Authorization Server (AS) to proxy introspection requests to the token’s authoritative issuer
• Ensures tokens can be validated securely, even when multiple proxies and ASes are involved

Interoperability Architecture

At the architectural core of AARC is the SP-IdP-Proxy model, which reduces integration complexity and supports collaboration-driven identity management.

AARC-G045 – Blueprint Architecture (2019)

Introduces two key proxy roles, namely, the Community AAI and the Infrastructure Proxy.

• The Community AAI, operated by or on behalf of a research community, which manages user enrolment, group membership, roles, and other community-managed attributes
• The Infrastructure Proxy, operated at the infrastructure level, which acts as the single integration point for services. It connects to different Community AAIs and enforces infrastructure policies
• Layered model allows communities to manage their users and authorisation independently, while infrastructures provide the trusted integration point for services
• Services connect only to the Infrastructure Proxy, reducing integration complexity for service providers
• Together, Community AAIs and the Infrastructure Proxy provide a scalable and interoperable foundation for connecting communities, infrastructures, and services

AARC-G080 – Blueprint Architecture 2025 (in development)

Updates the BPA to reflect current practices and introduces a capability-based view

structured around four areas:

• Identity Management – covers authentication, identity lifecycle, and integration with external IdPs
• Collaboration Management – enables management of groups, roles, and collaboration-driven authorisation
• Infrastructure Integration –  enriches identities with infrastructure-specific attributes (e.g. resource capabilities, infrastructure roles)
• Site-local Integration – connects federated identities to local services and enforcing site-specific policies

AARC-G081 – Token Lifetime Recommendations (under final consultation)

Provides recommendations for operational lifetimes of access tokens and refresh tokens. Consistent practices are essential for reducing the risk of misuse while supporting cross-infrastructure interoperability.

• Access tokens verified offline (non-revocable):
• Default: 1 hour – typically long enough for login and use of a protected resource.
• Max: 6 hours – in line with incident response times.

• Access tokens verified online (revocable):
• Default: 1 hour – consistent with SAML session lifetimes.
• Max: 25 hours – allows for running short jobs and next-day result checks.
• Refresh tokens:
• Default: 30 days – chosen as roughly the geometric mean between a day and a year, balancing usability and security
• Max: 400 days – ensures periodic proof of user involvement.

AARC-G100 – Establishing Trust with OpenID Federation (in development)

Defines how AARC-compliant AAI services –such as Infrastructure Proxies and Community AAIs– establish trust using the OpenID Federation 1.0 specification.

• Relies on Trust Authorities (Trust Anchors and Intermediates) to provide authoritative statements about federation participants.
• Defines two trust models:
• G100.1 Basic Trust Model – based on registration of proxies with Trust Authorities and validation of trust chains.
• G100.2 Fine-grained Trust Model – adds use of Trust Marks and metadata policies to indicate compliance with frameworks such as REFEDS Assurance, Sirtfi, or Data Protection Code of Conduct
• Enables dynamic trust establishment without bilateral agreements, supporting both explicit and automatic client registration.
• Complements guidelines such as AARC-G052 (Proxied Token Introspection) by enabling secure trust paths between proxies in a scalable way.

Discovery and User Experience

These guidelines improve the usability of federated login by helping users find their Identity Provider and understand which services are available, reducing login friction and confusion, and supporting smoother end-user journeys. Additionally, the accessibility of federated logins needs to be considered in line, for example, with the latest ​​W3C Accessibility Guidelines (WCAG).

AARC-G061 – Identity Provider Hinting

Defines the aarc_idp_hint parameter, allowing services or proxies to guide users to the correct authenticating IdP or upstream proxy.

• Supports nested hints for complex routing

AARC-G062 – Discovery Service Selection

Defines the aarc_ds_hint parameter for suggesting which Discovery Service to use.

• Enables community- or infrastructure-specific discovery experiences

AARC-G063 – End Service Information

Introduces the aarc_service_hint parameter to signal to a Discovery Service which end-service the user is accessing.

• Allows Discovery Services to present context-specific IdPs (e.g. filtering based on assurance requirements)

• Improves clarity in multi-proxy login flows