Guideline on the exchange of specific assurance information between Infrastructures (AARC-G021)


Increasingly Research Infrastructures and generic e-Infrastructures compose an 'effective' assurance profile derived from several sources. The assurance elements may come from an institutional identity provider (IdP), from community-provided information sources, from step-up authentication services, and from controls placed upon the user, the community, or the Infrastructure Proxy through either policy or technical enforcement. Knowledge about the upstream source of either identity or authenticator can also influence the risk perception of the Infrastructure and result in a modification of the assurance level, e.g. because it has involved a social identity provider or perhaps a government e-ID. The granularity of this composite assurance profile is attuned to the risk assessment specific to the Infrastructure or Infrastructures, and is often both more fine-grained and more specific than what can reasonably be expressed by generic IdPs or consumed by generic service providers.

Yet it is desirable to exchange as complete as possible the assurance assertion obtained between Infrastructures, so that assurance elements need not be re-asserted or re-computed by a recipient Infrastructure or Infrastructure service provider.

This document describes the assurance profiles that are recommended to be used by the e-Infrastructures and research infrastructures AAI platforms to exchange user authentication information between infrastructures.


This document is now in final public comment

Assigned DOI: (this one was a bit challenging as we do not have a formal author list - too many undefined contribuants from AARC and AppInt)

Adopted license: CC-BY-4.0


Recasted document with specific scoping, rationale - and tightening the association with the REFEDS RAF framework - is now available:

public-commentable versions:

And a snapshot of the REFEDS RAF document (2018-02-15) for reference.


Specific Open Questions (Feb 1st) Addressed:

Other comments addressed

QAddressed by
References to other (potentially future) guidelines
add to each of the guideline documents:
  "This Guidelines should be used and interpreted in the context of the
   AARC Blueprint Architecture ( and
   the AARC Policy recommendations ("

so that we don't have to re-iterate the references every time?

On the subject of Darjeeling, if we are asserting both Espresso and MFA, then you would assert Darjeeling, Espresso (as per the "superset" rule), *and* MFA *and* components (as per the components rule), so this kind of suggests Darjeeling is mostly redundant even if some infrastructure had a use case for it.

Dropped as by rough consensus

if you have, say, BIRCH plus MFA, then you can't assert BIRCH? ... because the BIRCH profile says SFA, so your values are no longer a superset.

This actually links to a long-standing discussion in the REFEDS RAF WG, which concluded that - however strange it may seem - SFA is not a subset of MFA.

In the MFA profile it puts nowhere any quality requirements on any of the factors. It is unlikely that thsi will change, since MFA has been recently adopted by REFEDS and they do not want to change it. As a result, we conclude here that we need some additional specs on the MFA to make this happen. Under implementation notes in the document there is now a specific paragraph addressing this:
"If the authentication assurance component meets the REFEDS-MFA criteria and the CSP can determine that at least one of the factors also meets the good practice requirements for REFEDS-SFA..."

Auditability and tracability of decisions in the proxy, or the business logic inside the proxy should be consideredAlthough very true, this is out of scope of this specific guideline document.

Meetings schedule and Minutes

Mailing list discussion only