1 of 77

Licia Florio, NORDUnet, licia@nordu.net

David Groep, Nikhef & Maastricht University, davidg@nikhef.nl �Christos Kanellopoulos, GEANT, christos.kanellopoulos@geant.org

Supporting access for research communities with the BPA

What is maturing under the broad-leaved AARC-TREE

TNC24 Rennes

“The Trust Roots That Make Research Grow”

Authentication and Authorisation for Research and Collaboration

https://aarc-community.org

2 of 77

We live in a federated world! With researchers collaborating across borders

https://aarc-community.org

3 of 77

Collaboration: an inherently-cross-domain issue .. and an AARC solution?

Example from the LHC Computing infrastructure WLCG

170 sites�~50 countries & regions�~20000 users

just how many interactions ??

people photo: a small part of the CMS collaboration in 2017, Credit: CMS-PHO-PUBLIC-2017-004-3; site map: WLCG sites from Maarten Litmaath (CERN) 2021

AuthN & AuthZ, architecture and trust should �align with collaboration structures, and �be outward facing: open, scalable, & multi-domain

https://aarc-community.org

4 of 77

AARC Blueprint Architecture: one BPA many communities

https://aarc-community.org

5 of 77

What is the AARC BPA?

The Authentication and Authorization For Research and Collaborations BluePrint Architecture provides a set of building blocks for software architects and technical decision makers who are designing and implementing access management solutions for international research collaborations. By design the AARC BPA is technology agnostic and provides an architectural design for those the deploy AAIs.

Science Clusters, Research Infrastructures and e-Infrastructure Providers have been been implementing their AAIs using the AARC Blueprint Architecture in order to manage their users and the access rights to resources

https://aarc-community.org

6 of 77

Interoperability – more than just the nice colours

https://aarc-community.org/guidelines/

https://aarc-community.org

7 of 77

An AARC BPA to enable federated access for eScience

Authentication and Authorization for Research Collaboration – https://aarc-community.org/

Access services using identities from users’ Home Organizations, but hide complexity of multiple IdPs, federations, AA technologies
One persistent identity across all the community’s services through account linking
Access services based on role(s) users have in the collaboration.
For both web and non-web resources
Integration of guest identity solutions
Support for stronger authentication assurance mechanisms

https://aarc-community.org

8 of 77

The AARC BPA: the IdP-SP proxy

Access services using identities from users’ Home Organizations, but hide complexity of multiple IdPs, federations, AA technologies
One persistent identity across all the community’s services through account linking
Access services based on role(s) users have in the collaboration.
For both web and non-web resources
Integration of guest identity solutions
Support for stronger authentication assurance mechanisms

Authentication and Authorization for Research Collaboration – https://aarc-community.org/

Graphics: Ann Harding and Lukas Hammerle (SWITCH )– from a long time ago now!

https://aarc-community.org

9 of 77

The Community AAI and the Infrastructure Proxy – structuring elements

Infrastructure Proxy

The Infrastructure Proxy, enables Infrastructures with a large number of resources, to provide them through a single integration point, where the Infrastructure can maintain centrally all the relevant Policies and business logic for making available these resources to multiple communities

Community AAI

The purpose of the Community AAI is to streamline researchers’ access to services, both those provided by their own infrastructure as well as the services provided by infrastructures that are shared with other communities.

https://aarc-community.org

10 of 77

AARC TREE: new funding to enhance the impact of AARC

https://aarc-community.org

11 of 77

AARC Technical Revision to Enhance Effectiveness

Recommendations for a common long-term strategy for AAI services

AARC TREE Project Main Facts

Start date: March 2024

Duration: 24 M

22 Partners

NDN coordinator

2,5 M Euro

Updated AARC BPA

Updated interoperability framework

Bring RIs, e-Infrastructures and relevant stakeholders together

https://aarc-community.org

12 of 77

AARC Technical Revision to Enhance Effectiveness

Recommendations for a common long-term strategy for AAI services

AARC TREE Project Main Facts

Start date: March 2024

Duration: 24 M

22 Partners

NDN coordinator

2,5 M Euro

Updated AARC BPA

Updated interoperability framework

Bring RIs, e-Infrastructures and relevant stakeholders together

Make AARC3 a global activity to engage �everyone interested in the evolution of AARC BPA

https://aarc-community.org

13 of 77

Challenges to address in AARC TREE

Interoperability with broader provider base

(IdPs, eIDs, social IdPs)

Requirements for assurance

Digital wallets

Better uptake and integration of the BPA

Proliferation of AARC Proxies

Service account information

https://aarc-community.org

14 of 77

AARC Community - open for all

AARC Engagement Group for Infrastructures

The forum of e/r-Infras that operate an AARC BPA complaint AAI.

It’s a closed group on purpose as we want to get feedback from the hands on group.

They approve the AARC guidelines.

Technical WG

Led by Nicolas and Christos
Where technical guidelines are discussed
Anybody can join the discussion:

https://lists.geant.org/sympa/info/aarc-architecture

Policy WG

Led by Dave and David
Supported by EnCo and IGTF
Anybody can join the discussion: policy@aarc-community.org�https://lists.geant.org/sympa/info/aarc-na3

https://aarc-community.org

15 of 77

Right now in AARC TREE:

Time to engage ?

Use Cases Collection and Analysis

with the large ESFRI RIs, clusters, and national nodes to validate BPA effectiveness and act as a flywheel to increase its application

Compendium & Recommendations

Have the validators and use cases have a broader impact by promoting them as ‘community good practice’ examples – and telling the world about it.

https://aarc-community.org

16 of 77

Dedicated work package to collect requirements from (new) communities

Landscape analysis of AARC BPA adoption

Conduct an AARC BPA adoption survey among the RIs,�online survey accompanied by the arranged conversations with the individual RIs
Collect information on current deployment of AARC BPA AAIs and adoption of guidelines

Result: Landscape analysis of AARC BPA adoption (around December 2024)

Use cases requirements & consultations

Design and create survey (including technology and policy questions) �based on FIM4Rv2 paper, Evolution, EOSC AAI TF requirements
Engage FIM4R, AEGIS, EOSC AAI TF, National Ris, EU data spaces to capture requirements
Discus with our ESFRIs to get expectations & requirements via consultations, workshops etc

Result: Use cases requirements described in a white paper (target Q1 2025)

Handover to Compendium

https://aarc-community.org

17 of 77

Compendium and Recommendations

Key result in the ‘2^nd year’ (April 2025 - February 2026) is the Compendium

'compendium of AARC best practices’ with recommendations for a common long-term strategy for AAI services in pan-European Research Infrastructures in Europe

based on the use case input and researcher requirements
promotes coherent and interoperable architecture and policy
iterate and validate with the infrastructures at large

describe the road that collaborative research infrastructure AAI will take!

https://aarc-community.org

18 of 77

Part II: AARC BPA Technical Guidelines

https://aarc-community.org

19 of 77

https://aarc-community.org

20 of 77

And of course with more AARC Compliant AAIs come more proxies

… it’s time for a Technical Revision to Enhance Effectiveness!

https://aarc-community.org

21 of 77

Community User Identifiers (CUID)

Problem

How to identity the user uniquely and persistently across AAIs that implement the AARC BPA

Guidelines

AARC-G026 - Guidelines for expressing community user identifiers

Summary

A subject identifier, where the subjects are generally but not exclusively natural persons.
Identifies the subject across AAIs
Non-reassignable, persistent
Managed by the Community AAI

https://aarc-community.org

22 of 77

Authorisation and affiliation in community use cases

Problem

How to communicate affiliation of a user with the community

Guidelines

https://aarc-community.org

1. Affiliation within Home Organisation, such as a university, research institution or private company; 2. Affiliation within Community, such as cross-organisation collaborations.

A proxy SHOULD NOT assert vPEA unless the service provider requests this attribute. If no origin ePSA attribute is provided, and no vPEA is requested by the service provider, then a proxy MUST NOT construct a gratuitous vPEA. If a service provider requests vPEA, but no ePSA is provided by the origin, a proxy SHOULD infer or construct a vPEA, and if it does, MUST do so only in accordance with this Guideline.

The origin affiliation, of the form affiliationtype@scope, and conveyed by the proxy to service providers in the vPEA attribute, MUST be constructed in the following way 1. If the origin provides eduPersonScopedAffiliation, its value MUST be used verbatim. 2. If the origin provides eduPersonAffiliation, and the scope of the origin provider can be reliably determined, the vPEA MUST be constructed by concatenating the value of eduPersonAffiliation provided, the “@” (at) sign, and the scope of the origin provider as determined according to the verification rules below. 3. If the origin does not provide any affiliation information, but the scope of the origin provider can be reliably determined, the vPEA MUST be constructed by concatenating the string literal “unknown@” and the determined scope of the origin provider. The reliable value of scope for the origin provider MUST be determined in accordance with the verification rules below. The potential for collision of the value literal “unknown” also being obtained from the origin provider is acknowledged, but this will not change the way the vPEA will be constructed. A reliable value of scope for the origin provider MUST be: a) from the trusted source of meta-data with which the assertion coming from the origin provider is validated, specifically the value of shibmd:scope from the eduGAIN metadata; or b) from a (verified) iss claim; or c) from the value of the schacHomeOrganisation attribute, if that attribute is asserted in the same attribute statement that contains the eduPersonAffiliation; or d) from the scope element of another scoped attribute whose scope has been validated against a trusted source, e.g., eduPersonPrincipalName; or e) from matching the attribute signing certificate with that of a public registry of identity providers where the domain-name part of the provider is validated to at least browser-trust domain-control validation standards1; or f) from an explicit validation of the value of scope assigned to that identity provider which confirms its managerial control over the name in the public domain name system corresponding to the scope value.

23 of 77

Parte III: How to Establish Trusted and Secure Operations

https://aarc-community.org

24 of 77

Policy and good practice underpinning the AARC Blueprint BPA

Infrastructure alignment and policy harmonisation: helping out the proxy

Operational Trust for Community and Infrastructure BPA Proxies
Increase acceptance of research proxies by identity providers through common baselines
Review infrastructure models for coordinated AUP, T&C, and privacy notices, improving �cross-infrastructure user experience (users need to click only once)

User-centric trust alignment and policy harmonization: helping out the community

Lightweight community management policy template
Guideline on cross-sectoral trust in novel federated access models
Assurance in research services through (eIDAS) public identity assertion

https://aarc-community.org

25 of 77

How to establish secure operation for your (AARC BPA) proxy?

The Challenge

How to securely operate proxies, attribute authorities and issuers of statements for entities?

Guideline

AARC-G071 Guidelines for Secure Operation of Attribute Authorities

Summary

Operational security processes and procedures
Requirements on traceability, auditability, and logging
Requirements on the secure operation
Requirements on securing the interactions

https://aarc-community.org

26 of 77

Operational guideline landscape for - proxy or source - AAI components

Authentication/identity sources

Sirtfi

(eduGAIN) baselining, RAF

IGTF AP Profiles

NIST SP800-63

eduGAIN sec. team workflow

RFC6238/4226�FIPS140

NIST SP800-53

REFEDS MFA

Service provider operations

ISO27k

Sirtfi

Infrastructure response plans

Ephemeral credentials

trusted credential stores
protection at rest

https://aarc-community.org

27 of 77

Operational security focus in the BPA: beyond just the IdPs

Guidelines for Secure Operation of Attribute Authorities and other issuers of access-granting statements �(AARC-I048, in collaboration with IGTF AAOPS)

Community membership management directories and attribute authorities

integrity of membership
identification, naming and traceability
site and service security
protection on the network
assertion integrity

Community membership management directories and attribute authorities

integrity of membership
identification, naming and traceability
site and service security
protection on the network
assertion integrity

https://aarc-community.org

28 of 77

When the AA is in a managed environment …

Many of the recommendations are already implemented ‘implicitly’

because common software implements it: e.g. signing SAML assertions and JWTs
because a good data centre already has network monitoring and central logging in place
because you signed up to Sirtfi (didn’t you?) – so you collaborate in incident response
because you have trained IT operations personnel looking after the service

And some are intuitive best practice

like assigning a unique and lasting name to a group
because implemented controls ought to be those that have been documented

Some items contain reminders about appropriate values and recommendations � that are good practice - based on the relevant standards involved

https://aarc-community.org

29 of 77

Deployment guidance included …

https://aarc-community.org

30 of 77

AARC-G071 Example requirement: Attribute Assertions

AAS-3

If an AA Operator issues assertions containing a lifetime, this lifetime must be compliant with the Community policies, as short as reasonably possible, and the assertion must not be valid beyond the validity period of the attributes it contains. The Community Management is responsible for the content of the assertion, as issued, during its entire lifetime

AAS-4

Re-issuance of assertions must be based on information held in the AA at the time of re-issuance.

https://aarc-community.org

31 of 77

AARC-G071 example requirement: Operational Environment

OE-1

Through its personnel or by contractual measures, the AA Operator should ensure appropriate controls are in place over the security context.

OE-2

The AA must be located in a physically secure environment where access is controlled and limited to specific trained personnel.

OE-3

The protections on the AA and its operational environment, including the credentials of the AA administrators and operators, should meet or exceed the requirements of all of the communities hosted in the AA.

https://aarc-community.org

32 of 77

AARC-G071 Example requirement: Assessment and Peer Review

AR-5

The AA operator must disclose and discuss, on request, those aspects of their operational environment that are relevant to the evaluation of the security and trust by the Communities and Relying Parties.

AR-6

The AA Operator must be able and willing to collaborate with affected organisations in the management of a security incident.

AR-7

The AA Operator should review roles, rights, and access of its staff at least once per year.

https://aarc-community.org

33 of 77

AARC-G071 Example requirement: Relying Party Obligations “the other side”

RP-1

Relying Parties must, at the time of reliance, verify the integrity and validity of attribute assertions and any binding to a valid subject, to their satisfaction.

RP-2

Relying Parties must rely on assertions with an explicit lifetime only during their validity period.

RP-3

Relying Parties must assess the risk of relying on assertions with no explicit lifetime and should not rely on them for longer than the relevant industry standards for that type of assertion recommend.

RP-4

Any long-lived, non-revocable statements received from an AA must be appropriately protected for confidentiality and integrity, by proxies and other intermediate entities.

https://aarc-community.org

34 of 77

Links to (probably) most well-known AARC outcome for security …

https://refeds.org/SIRTFI

Security Incident Response Trust Framework for Federated Identity

https://aarc-community.org

35 of 77

Our federated world is growing more complex

Images: SURF SSRAM and EGI by Maarten Kremers, NDFI AAI (Marcus Hardt), EOSC AAI for the EOSC Core and Exchange Federation for the EOSC European Node by Christos Kanellopoulos, Nicolas Liampotis, David Groep (June 2023 version)

https://aarc-community.org

36 of 77

Response and traceability across IdP-SP Proxies and the limits of Sirtfi

Guidelines for a joint operational trust baseline for membership management and proxy components, �supplemented by policy guidance for sectoral federations with more specific policies where needed

‘How can we convey the trust in what is in and behind the proxy?’
‘How to provide timely traceability between services and identities through the proxy?’

Based on requirements from FIM4R, WISE, and the proxy operators in AEGIS.

joint work with GN5-1 EnCo and eduGAIN CSIRT

images: AARC Sirtfi v1 exercise (Hannah Short), eduGAIN security TTX (Sven Gabriel, eduGAIN CSIRT)

Srtfi v1

|CSIRT

https://aarc-community.org

37 of 77

Proxies have more challenges as well: AUPs, T&Cs, Privacy notices, …

For large ‘multi-tenant’ proxies

some subset users in some communities use a set of services – �how to present their Terms and Conditions and their privacy policies, so that users

only see the T&Cs and notices for services they will access
this does not to need to be manually configured for each community
is automatically updated when services join

For community and dedicated proxies

when new (sensitive) services join, who needs to see the new T&Cs?
can we communicate existing acceptance of T&Cs to downstream services?

What is an acceptable user experience in clicking through agreements? �What is effective in exploiting the WISE Baseline AUP? What do researchers need?

‘with fewer clicks to more resources’

beyond AARC-G040

https://aarc-community.org

38 of 77

Helping out the community: the policy toolkit for communities & trust

“small to mid-sized communities do not have the resources to maintain a bespoke community management policy”

this leaves communities and SP operators unclear about trust assurance level of members

Today’s BPA proxy links attributes as well as trust

And what about assurance: we’ll have more, and maybe more reliable, sources of assurance in the near term?

https://aarc-community.org

39 of 77

Production Implementations of the AARC BPA�EOSC and MyAccessID as Real Life Examples

https://aarc-community.org

40 of 77

Production Implementations: EOSC

EOSC Access Federation

Registers, maintains, and publishes the trust anchors and the associated metadata for all the entities in the EOSC Federated AAI. Provides common horizontal functionalities.

Identity Hub

Provides user authentication and consistent user information to services in the EOSC Federated AAI.

EOSC Core Infrastructure Proxy

Connects the EOSC Core Services

EOSC Exchange Infrastructure Proxy

Connects the EOSC Exchange Services

X509v3 Token Translation Service (TTS)

Authenticates users with their X.509v3 credentials.

https://aarc-community.org

41 of 77

Production Implementations: MyAcademicID

MyAcademicID Service

The MyAcademicID Service was launched in November 2020 MyAcademicID Project

EWP+ / University Alliances��Provides an Authentication Proxy for the core Erasmus+ services (Online Learning Agreement, Dashboard, the Erasmus+ App).

eduGAIN, eIDAS & Google Authentication��Supports authentication via eduGAIN, eIDAS and Google

Provides a catch-all IdP of Last Resort

https://aarc-community.org

42 of 77

Production Implementations: MyAccessID

HPC Datacenters are in the process of transforming to Infrastructure Service Providers with a diverse Service Portfolio
These infrastructure services become available in different administrative and policy domains, which we call Infrastructure Service Domains
A common Authentication and Authorization Infrastructure enables uniform accessibility to scientists and engineers at European scale

https://aarc-community.org

43 of 77

MyAccessID: A common AAI for ISDs in HPC

Isambard

44 of 77

Production Implementations: MyAccessID

https://aarc-community.org

45 of 77

Authorisation and affiliation in MyAccessID/Fenix example

https://aarc-community.org

46 of 77

Level of Assurance in MyAccessID/EuroHPC

2020

2021

2022

2023

2024

PUHURI 1 project start

MyAccessID & PUHURI Design

MFA - Strong Authentication Pilot

MyAccessID & PUHURI Pilot

MyAccessID & PUHURI Production

LUMI General Availability

Policy for Quality of Identities/LoA

LUMI Pilots

Community coordination on LoA

Implement policy on LoA

External Identity Vetting Pilot

2025

MFA - Strong Authentication

External Identity Vetting

https://aarc-community.org

47 of 77

Assurance information in identity linking

Problem

How to evaluate assurance information when linking identities

Guidelines

Summary

Identifier uniqueness: AND function → Cannot assert unique ID for the combined evaluation when one of the linked identities lacks it
Identity proofing: resolves to the effective identity used
Step-up Identity proofing: if the identifier uniqueness and level of authentication are the same, LoA can be assigned to the weaker identity
Step-up Authentication: user may register a second authentication factor to enhance the strength of the authentication method and effectively the associated LoA

https://aarc-community.org

5.1.1 Linked High-LoA Identity The following LoA elevation flow considers all components of the LoA associated with linked identities: A user registers for an infrastructure identity with a low-LoA identity, e.g. from a social media identity provider lacking identity vetting. Subsequently, the user links their high-LoA organisational identity to their infrastructure identity. However, by linking the two identities, the user has proved that they are the same user. Assuming both providers meet the same requirements with respect to the uniqueness of the identifiers and the authentication strength, the infrastructure may assign a high LoA when the user logs in using the social media identity, since it has been linked to a high-LoA organisational identity that makes up for the lack of identity vetting.

5.1.2 Step-Up Authentication There are also types of linked identities that do not support sufficiently strong authentication methods for highrisk access use cases, despite being otherwise trustworthy (e.g. from the point of view of the identity vetting process). In such cases, the user may register a second authentication factor to enhance the strength of the authentication method and effectively the associated LoA (step-up authentication).

48 of 77

Level of Assurance in MyAccessID/EuroHPC

2021

2022

2023

Plan

Reality

LUMI requirements translated into LoA

MyAccessID warning message 1. March deadline

Users react

LUMI reacts

Deadline changed for later in 2023

Start to work on alternative solution: Identity vetting

Regular coordination with federation operators

LoA requirements socialised within LUMI consortium and wider

LoA tracking shows about 15% adoption

LoA tracking shows improvement 23% adoption

Well accepted, half of the partners declared support by their federation already

Well received, triggered internal discussion to adopt LoA in several federations

Identity vetting through eduid.se implemented

LoA policy enforced

https://aarc-community.org

49 of 77

Level of Assurance in MyAccessID/EuroHPC

https://aarc-community.org

50 of 77

Thanks to the AARC Community, including folk from whom we re-used graphics and material in this overview. In random order: Licia Florio, Nicolas Liampotis, Christos Kanellopoulos, Marina Adomeit, Janos Mohacsi, Ilaria Fava, Slavek Licehammer, Dave Kelsey, Ian Neilson, Marcus Hardt, Mischa Salle, Hannah Short, and Maarten Kremers.

Thank you

Any Questions?

The work leading to these results has received funding from the European Union and other sources.

https://aarc-community.org

Co-funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union. Neither the European Union nor the granting authority can be held responsible for them. Grant Agreement No. 101131237 (AARC TREE).

Co-funded by �the European Union

https://aarc-community.org

51 of 77

Core AAI Platform Roadmap

Christos Kanellopoulos (GEANT)

52 of 77

Core AAI Platform

53 of 77

54 of 77

Core AAI Platform Roadmap

2018

2019

2020

2021

2022

2023

2024

2025

2026

FENIX Design

FENIX�Implementation

FENIX

Pilot

FENIX Production

MyAccessID & PUHURI Pilot

MyAccessID & PUHURI Design

MyAccessID & PUHURI Production

Federated�SSH CA

PoC

MFA - Strong Authentication

EUDI Wallet Pilot

Support for Advanced Use Cases

Identity�Vetting Pilot

EuroHPC Federated Platform

Federated�SSH CA

Pilot

Identity Vetting PoC

MyAccessID FENIX Production

55 of 77

The Core AAI Platform - Features

Why am I mentioning the platform itself? Because we are designing and developing new features for the whole platform.

I chose those six on purpose as they could be interesting also for your research infrastructure:

One unique ID for scientists and researchers to provide uniform experience in the access to services and resources.
Multi-Factor authentication supported by the platform itself in situations where services are not able to handle this and want to still benefit from the higher security.
Identity vetting (proofing or verification) as a service to provide a way how user can provide a proof of their identity by eIDAS or by the Passport verification process as some services needs to be sure that user was verified before get access to their resources.
Federated SSH CA solution as a replacement for standard SSH keys, where users can get an SSH certificate on request simply using the federated access.
A Service Management to simplify the process of registering new services to the Core AAI Platform
Support of ORCID attributes for users who has an ORCID iD

All mentioned functionalities except the unique ID are now in the middle of development and deployment with a production versions as part of the Core AAI Platform (MyAccessID) in 2024.

56 of 77

Identity vetting

57 of 77

Multi-Factor Authentication

58 of 77

The federated SSH CA

59 of 77

MyAccessID: A common AAI for ISDs in HPC

60 of 77

MyAccessID: A common AAI for ISDs in HPC

61 of 77

MyAccessID: A common AAI for ISDs in HPC

62 of 77

Core AAI Platform Roadmap

2018

2019

2020

2021

2022

2023

2024

2025

2026

FENIX Design

FENIX�Implementation

FENIX

Pilot

FENIX Production

MyAccessID & PUHURI Pilot

MyAccessID & PUHURI Design

MyAccessID & PUHURI Production

Federated�SSH CA

PoC

MFA - Strong Authentication

EUDI Wallet Pilot

Support for Advanced Use Cases

Identity�Vetting Pilot

EuroHPC Federated Platform

Federated�SSH CA

Pilot

Identity Vetting PoC

MyAccessID FENIX Production

Registrar�Pilot

EUDI Wallet Pilot

63 of 77

Thank you

Christos Kanellopoulos (GEANT)

64 of 77

For Reference - Current Work in Progress

https://aarc-community.org

65 of 77

More complex Examples

https://aarc-community.org

66 of 77

OpenID connect - complex topologies, how do we enable trust

https://aarc-community.org

67 of 77

OpenID connect - complex topologies, how do we enable trust

Problem

How to convey 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.

Guideline

AARC-G052 OAuth 2.0 Proxied Token Introspection
AARC-G058 Establishing trust between OAuth 2.0 Authorization Servers
AARC-GXXX OAuth2 Token Profile

Summary

Models for validating tokens across infrastructures
Establishing trust across interfederations of AAIs
Speaking the same language

LAST CALL

WIP

TODO

https://aarc-community.org

68 of 77

AARC-G052 OAuth 2.0 Proxied Token Introspection

Offline Token Validation by the RS

Token introspection (RFC7662) invoked by RS, with offline token validation performed by AS

Token introspection invoked by RS, with proxied token introspection performed by the AS

https://aarc-community.org

69 of 77

Offline token validation performed by the RS

https://aarc-community.org

70 of 77

Token introspection (RFC7662) invoked by RS, with offline token validation performed by AS

https://aarc-community.org

71 of 77

Token introspection invoked by RS, with proxied token introspection performed by the AS

https://aarc-community.org

72 of 77

AARC-G052 OAuth 2.0 Proxied Token Introspection

Approach	Advantages	Disadvantages
Offline token validation performed by RS	Does not require callout to token issuer Works with standard client and AS libraries	Trust scalability: Each RS needs to trust all token issuers Tokens MUST contain the authorisation claims Does not support token revocation
Token introspection (RFC7662) invoked by RS, with offline token validation performed by AS	Trust scalability: Only the AS Proxy needs to trust tokens issuers	Requires callout from RS to AS Proxy Tokens MUST contain the authorisation claims Does not support token revocation Requires modifications to AS libraries
Token introspection invoked by RS, with proxied token introspection performed by AS	Trust scalability: Only the AS Proxy needs to trust tokens issuers Supports token revocation	Requires callout from RS to AS Proxy and from AS Proxy to token issuer Requires modifications to AS libraries

https://aarc-community.org

73 of 77

Evolve the BPA to address the more complex (and the simpler) worlds

guidelines for harmonising expression of community user attributes

reduce inconsistencies between implementations
improve interoperability & end-user usability across research community communities and infrastructures

Authorisation guidelines

best practises to enable efficient & effective sharing of federated resources

Decentralised identities

guidance for digital wallets linked to BPA

Extend AARC BPA

improve scalability
leverage emerging standards �like OpenID Federation

2025

https://aarc-community.org

74 of 77

How to express community identity attributes?

“How to express the identifier of a user?” �→ AARC-G026
“How to express the groups and roles of a user?” �→ AARC-G069 (was AARC-G002)
“How to express resource capabilities of a user?” �→ AARC-G027
“How to express the home institute of a user?” �→ AARC-G025
How to express user assurance information�when interacting with another proxy?” �→ RAF & AARC-G021

AARC-G056

https://aarc-community.org

75 of 77

AARC Blueprint Architecture ‘BPA2025’!

OpenID Federations

AuthZ for Federated Resources

Decentralised Identities & Wallets

AARC BPA 2025

AARC BPA 2019

https://aarc-community.org

76 of 77

Additional resources

https://youtu.be/Xpwb6BNxNW4

https://aarc-community.org/

https://aarc-community.org

77 of 77

Thank you

Any Questions?

The work leading to these results has received funding from the European Union and other sources.

https://aarc-community.org

Co-funded by �the European Union

https://aarc-community.org