Uncategorized

There has been a lot of discussion about assurance in the research and education space over the past year. A previous blog written by Mikael Linden describes the work done by the REFEDS Assurance working group and the key aspects of the REFEDS Assurance Framework (RAF) approved in October 2018. This post complements Mikael’s post by adding further details on REFEDS authentication profiles and AARC guidelines on assurances.

Please note that a webinar on assurance is scheduled for Dec 13th.

To manage risks related to the access control of their services, the relying parties of research and education federations need to make decisions on how much they can trust the assertions made by the Identity Providers (IdPs). In federated identity management the assurance posture depends on the policies and  practices of the user’s Home Organisation (its IdP and the back-end identity management system, together dubbed as a Credential Service Provider) and the identity federation to which it belongs. Questions that relying parties would ask are for instance, can this user ID be later reassigned to some other person? How fresh is that affiliation information? How was the user authentication done?

The IdPs on their side need specific guidance as to what is needed in terms of assurance, expressed in a form that allows them to make confident assertions and allows Service Providers to easily parse that.

What are the benefit of REFEDS RAF ?

The RAF does not follow a monolithic approach, but instead defines a scalable framework that splits assurance into the following orthogonal components:

  • the identifier uniqueness;
  • the identity assurance; and,
  • the attribute assurance.

To keep things simple, the components are mounted into two profiles, named generically cappuccino and espresso. Based on the use-cases, these two profiles can be used stand-alone or in combination with the REFEDS Authentication Profiles Single Factor Authentication (SFA) and Multifactor Authentication (MFA).

Fig 1: Split of responsibility between REFEDS specs (courtesy of Mikael Linden)

Fig 2: “Cappuccino” for low-risk research use cases (courtesy of Mikael Linden)


Fig 3: “Espresso” for more demanding use cases (courtesy of Mikael Linden)

The output of the RAF also specifies how to represent the values using existing federated identity protocols, currently SAML 2.0 and OpenID Connect; this makes the framework immediately usable by federation operators and credentials service providers.

The SAML Identity Provider’s support can be tested for instance in the SWITCHaai attribute viewer service. The support for Service Providers is even easier as it needs to just request the authentication context it wishes and observe the resulting authentication context and eduPersonAssurance attribute value.

The REFEDS well defined processes and consultation ensured that the RAF framework was agreed by a large and relevant audience (i.e., research infrastructures and federation operators) and that the framework will be maintained and updated as needed in the future.

What do the REFEDS Authentication Profiles Add?

Although authentication factors are related to assurance, RAF itself does not impose requirements on the authentication; instead two different authentication profiles were defined: Multi-factor Authentication Profile (MFA) and Single Factor Authentication Profile (SFA). These profiles define the requirements that an authentication event must meet in order to communicate the usage of a specific profile. While a user’s RAF attribute value can be static and seldom changes, the authentication can change in any authenticated session and the relying service can request the IdP to use a particular authentication profile. In short:

  • RAF defines requirements for identifiers, identity proofing and attribute assurance.
  • SFA defines the requirements for single-factor authentication, such as passwords or soft certificates.
  • MFA defines the method for communicating multi-factor authentication as a SAML authentication context.

What do the AARC Assurance Guidelines Add?

The AARC Blueprint Architecture (BPA), with the aim to offloads tasks from the Service Providers, adds additional components such as a proxy, attribute authorities operated by or on behalf of Research and e-Infrastructures and token translation services. The ‘proxies’ in the AARC Blueprint Architecture are often able to augment assurance from various data sources, and account linking can both change and strengthen the assurance posture.

AARC has developed additional guidance to facilitate the exchange of assurance information across infrastructures (or between SP-IdP-Proxy components of infrastructures).

Supplementary AARC and IGTF assurance profiles targeting the specific research and infrastructures’ needs in terms of risk profiles help out: shared assurance profiles inspired by the Service Provider and infrastructure requirements can be exchanged directly and help evaluate identity assurance information for the attributes and authenticator presented both by the user’s home organisations via the R&E federations and from supplementary sources when enabling federated access to access services. The profiles are: