REFEDS Assurance Framework ver 1.0 has been superseded by version 2. Please go to REFEDS Assurance Framework on the REFEDS web for the current version.


To manage risks related to the access control of their services, the Relying Parties of the research and education federations need to make decisions on how much to trust the assertions made by the Identity Providers and their back-end Credential Service Providers. This document introduces a framework for assurance and its expression using common identity federation protocols.

This framework splits assurance into the following orthogonal components:

  • the identifier uniqueness;

  • the identity assurance; and

  • the attribute assurance.

The assurance of authentication is not covered by this specification. The Credential Service Provider assigns one or more values from one or more components to each credential and delivers the value(s) to the Relying Party in an assertion. For conformance to this framework, only meeting the baseline expectations for Identity Providers is required.

To serve the Relying Parties seeking for simplicity, the components are further collapsed to two assurance profiles (with the arbitrary names Cappuccino and Espresso) which cover all components. This framework also specifies how to represent the values using federated identity protocols, currently SAML 2.0 and OpenID Connect.

1. Terms and definitions




A set of data presented as evidence of a claimed identity

and/or entitlements [X.1254].

Credential Service Provider (CSP)

A trusted actor that issues and/or manages credentials [X.1254]. In the context of this specification, CSP refers to the Identity Provider and the associated Identity Management system that manages the user identities and attributes observed by the Relying Parties.

No re-assignment (of an identifier)

No re-assignment means that while a user can be assigned a new identifier value (such as, an eduPersonPrincipalName attribute value [eduPerson]), the old value MUST NOT be recycled to another user.

However, the identifier value can be assigned back to the same user (for instance, if a departed person later returns back to the organisation).

Relying Party (RP)

Actor that relies on an identity assertion or claim [X.1254].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

To assert the values defined in this profile to the RPs the CSPs will use URIs which have the following prefix:


2. Assurance components

This section introduces three assurance components which each represent a different aspect of assurance. The components are orthogonal: therefore, a CSP can assert one or more values from different components independently. The value pertains to the user represented in the assertion and different users can qualify to different values.

This framework does not define the assurance of user authentication. See other REFEDS specifications for authentication assurance.

2.1. Identifier uniqueness

This component describes how a CSP expresses that an identifier represents a single natural person and if that mapping of identifier to person remains the same over time.




The identifier MUST have the following four properties:

(Unique-1) The user identifier represents a single natural person

(Unique-2) The CSP can contact the person to whom the identifier is issued

(Unique-3) The user identifier is never re-assigned

(Unique-4) The user identifier is eduPersonUniqueId [eduPerson], SAML 2.0 persistent name identifier [OASIS SAML], subject-id or pairwise-id [OASIS SIA] or OpenID Connect sub (type: public or pairwise)

A CSP asserting $PREFIX$/ID/unique MUST NOT send a Relying Party any identifier listed in Unique-4 that does not meet Unique-1 through Unique-3.

In addition to the identifiers mentioned in Unique-4, eduPersonPrincipalName (ePPN, [eduPerson]) is a human-readable user identifier whose re-assignment practice is undefined by its specification. To support Relying Parties’ use of ePPN, the following extra values are defined to describe a CSP’s ePPN practices.

The values are mutually exclusive. A CSP MAY assert one of them but MUST NOT assert more than one.




eduPersonPrincipalName value has the Unique-1, Unique-2 and Unique-3 properties.


eduPersonPrincipalName value has the Unique-1 and Unique-2 property but may be re-assigned after a hiatus period of 1 year or longer.

The expected Relying Party behaviour for observing ePPN re-assignment

  • If the CSP asserts eppn-unique-no-reassign, the Relying Party knows that when it observes a given ePPN value it will always belong to the same individual.

  • If the CSP asserts eppn-unique-reassign-1y, the Relying Party knows that if an ePPN holder doesn’t show up for one year, the ePPN holder may have been changed. A safe practice for the Relying Party is to close a user account or remove the ePPN value associated to it if the user hasn’t logged in for one year. The Relying Party can also use some out-of-band mechanism to verify whether the user is still the same person.

  • If the CSP asserts neither eppn-unique-no-reassign nor eppn-unique-reassign-1y, the Relying Party cannot rely on ePPN as a unique user identifier but should use it only in combination with another identifier identified in the definition of Unique-4.

Finally, the reader is reminded that they should not assume any uniqueness property that goes beyond the specification of the attribute. For instance, a Relying Party should not assume that the holder of an ePPN value is the receiver of an email message sent using the ePPN value as the receiver address.

2.2. Identity proofing and credential issuance, renewal and replacement

This section describes the requirements for

  • Identity Proofing, which is the process by which the CSP captures and verifies sufficient information to identify a user to a specified or understood level of assurance [X.1254].

  • Credential issuance, which is the process of providing or otherwise associating a user with a particular credential, or the means to produce a credential [X.1254].

  • Renewal, which is the process whereby the life of an existing credential is extended [X.1254].

  • Replacement, which is the process whereby a user is issued a new credential, or a means to produce a credential, to replace a previously issued credential that has been revoked [X.1254].

These values constitute an ordered set of levels with increasing requirements. The CSP asserting a value high MUST also assert (and comply with) the value medium and low for a given user. The CSP asserting a value medium MUST also assert (and comply with) the value low for a given user.




Identity proofing and credential issuance, renewal, and replacement qualify to any of

  • sections 5.1.2- and section 5.1.3 of Kantara assurance level 1 [Kantara SAC]


  • IGTF level ASPEN [IGTF]

Example: self-asserted identity together with verified e-mail address, following sections sections 5.1.2- and section 5.1.3 of [Kantara SAC].


Identity proofing and credential issuance, renewal, and replacement qualify to any of

  • sections 5.2.2-, section and section 5.2.3 of Kantara assurance level 2 [Kantara SAC]

  • IGTF level BIRCH [IGTF]

  • IGTF level CEDAR [IGTF]

  • section 2.1.2, section 2.2.2 and section 2.2.4 of eIDAS assurance level low [eIDAS LoA]

Example: the person has sent a copy of their government issued photo-ID to the CSP and the CSP has had a remote live video conversation with them, as defined by [IGTF].


Identity proofing and credential issuance, renewal, and replacement qualifies to any of

  • section 5.3.2-, section and 5.3.3 of Kantara assurance level 3 [Kantara SAC]

  • section 2.1.2, section 2.2.2 and section 2.2.4 of eIDAS assurance level substantial [eIDAS LoA]

Example: the person has presented an identity document that is checked to be genuine and represent the claimed identity and steps have been taken to minimise the risk of a lost, stolen, suspended, revoked or expired document, following sections 2.1.2, 2.2.2 and 2.2.4 of eIDAS assurance level substantial [eIDAS LoA].

A CSP MAY also assert the following value independent of the values above:




The identity proofing and credential issuance, renewal and replacement are done in a way that qualifies (or would qualify) the user to access the Home Organisation’s internal administrative systems (see appendix A).

2.3. Attribute quality and freshness

This section describes the requirements for the quality and freshness of the attributes (other than the unique identifier) the CSP delivers to the RP.

The requirements are limited to the eduPersonAffiliation, eduPersonScopedAffiliation and eduPersonPrimaryAffiliation attributes defined in [eduPerson]. The freshness of the attribute is further limited to the following attribute values: faculty, student and member. Other values and attributes are out of scope.

The freshness of eduPersonAffiliation, eduPersonScopedAffiliation and eduPersonPrimaryAffiliation is intended to serve the RPs who want to couple their users’ access rights with their continuing institutional role.

The values are hierarchical. A CSP which asserts $PREFIX$/ATP/ePA-1d MUST assert also $PREFIX$/ATP/ePA-1m for a given user.




eduPersonAffiliation, eduPersonScopedAffiliation and eduPersonPrimaryAffiliation attributes (if populated and released to the RP) reflect user’s departure within 31 days time


eduPersonAffiliation, and eduPersonScopedAffiliation and eduPersonPrimaryAffiliation attributes (if populated and released to the RP) reflect user’s departure within one days time

“A departure” takes place when the organisation decides that the user doesn’t have a continuing basis for the affiliation value and therefore loses their organisational role and privileges (i.e., can no longer speak for the organisation in that role). The organisational business practices here may vary; for instance

  • In some organisations a researcher loses their organisational role and privileges the day their employment or other contract ends, in some organisations there is a defined grace period

  • In some universities a student loses their organisational role and privileges the day they graduate, in some organisations the student role and privileges remain effective until the end of the semester

This specification imposes no particular requirements on the organisational business practices regarding when the departure takes place. This value is intended to indicate only the  maximum latency for the CSP’s identity management system to reflect the departure in the user’s attributes.

Notice also that this section does not require that the departing user’s account must be closed; only that the affiliation attribute value as observed by the RPs is updated.

3. Conformance criteria

For a CSP to conform to this profile it is REQUIRED to conform to the following baseline expectations for Identity Providers:

1. The Identity Provider is operated with organizational-level authority

2. The Identity Provider is trusted enough that it is (or it could be) used to access the organization’s own systems

3. Generally-accepted security practices are applied to the Identity Provider

4. Federation metadata is accurate, complete, and includes at least one of the following: support, technical, admin, or security contacts

A CSP indicates its conformance to this profile by asserting $PREFIX$.

4. Assurance profiles

To serve the RPs seeking for simplicity, this section collapses the components presented in section 2 and 3 into two assurance profiles Cappuccino and Espresso.

The CSPs who populate the assurance assertions presented in the section 2 SHOULD populate also all assurance profiles to which they qualify.

The table below defines the following assurance profiles:

  • Assurance profile Cappuccino for low-risk research use cases ($PREFIX$/profile/cappuccino)

  • Assurance profile Espresso for use cases requiring verified identity ($PREFIX$/profile/espresso)

A CSP qualifies to a profile if it asserts (and complies with) all the values marked as ‘X’ in the column.






















X (*)

X (*)


(*) The CSP can omit this requirement if it doesn’t populate and release the attribute values defined in section 2.3 for this user.

For instance, if a user qualifies to all values required according to the column “Espresso” the CSP SHOULD assert Espresso for this user.

Notice that the assurance profiles do not cover the authentication assurance of the user session. The deployers are encouraged to use the profiles in conjunction with specifications focusing on authentication.

5. Representation on federated protocols

This section specifies how the values presented in the previous section shall be represented using federated identity protocols.

5.1. Security Assertion Markup Language 2.0 (SAML)

In SAML, this assurance framework is represented using the multi-valued eduPersonAssurance attribute, as defined in [eduPerson]. See Appendix B for examples.

5.2. OpenID Connect (OIDC)

In OIDC, this assurance framework is represented using the multi-valued eduPersonAssurance claim, as defined in [REFEDS OIDCre]. See Appendix B for examples.

6. References


Internet2/MACE. eduPerson Object Class Specification (201602).


European Commission. Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015 on setting out minimum technical specifications and procedures for assurance levels for electronic identification means.

ePSA Comparison

Cormack, A., Linden, M. REFEDs ePSA usage comparison, version 0.13.


Groep, D (editor). IGTF Levels of Authentication Assurance, version 1.0.

Kantara SAC

Kantara Initiative. Kantara Identity Assurance Framework. KIAF-1420 Operational -63r2 Service Assessment Criteria. Version 1.0. Publication Date 2018-03-21.


Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS Standard. 15 March 2005.


SAML V2.0 Subject Identifier Attributes Profile Version 1.0. Committee Specification Draft 02 / Public Review Draft 02. 10 April 2018.


OpenID Connect for Research and Education Working Group. Mapping SAML attributes to OIDC Claims. Referenced 9 February 2018.  


Bradner, S. Key words for use in RFCs to Indicate Requirement Levels. RFC2119.


International Telecommunication Union. Series X. Data Networks, Open System Communication and Security. Cyberspace security – Identity management. Entity authentication assurance framework. Standard X.1254.

Appendix A: Local enterprise -- Good enough for internal systems

Some of the components in section 2 define an assurance level implicitly by a statement that the level of assurance is good enough for accessing the Home Organisation’s internal systems. This relies on the assumption that if the Home Organisation deems the assurance level good enough for accessing internal systems locally in the Home Organisation, the assurance level may be good enough for accessing some external resources, too. It is assumed that the Home Organisation has made a risk based decision on what exactly are the assurance level requirements for those accounts.

Home Organisations may have several internal systems with varying assurance level requirements. It is assumed that the Home Organisation’s internal systems referred to here could be:

  • The ones that deal with money (for instance, travel expense management systems or invoice circulation systems)

  • The ones that deal with some employment-related personal data (for instance, employee self-service interfaces provided by the Human Resources systems)

  • The ones that deal with student information (for instance, administrative access to the student information system)

Appendix B: Examples on assurance values

A university who guarantees that its faculty members

  • Have unique ePUID values

  • Are ID-proofed face-to-face using government-issued photo-ID

  • eduPerson affiliation value(s) reflects their departure or role change promptly

  • Identity management system qualifies to the baseline expectations for Identity Providers

Will assert to its faculty members the following multi-valued assurance assertion:

  • $PREFIX$
  • $PREFIX$/ID/unique
  • $PREFIX$/IAP/local-enterprise
  • $PREFIX$/IAP/low
  • $PREFIX$/IAP/medium
  • $PREFIX$/IAP/high
  • $PREFIX$/ATP/ePA-1m
  • $PREFIX$/ATP/ePA-1d
  • $PREFIX$/profile/cappuccino
  • $PREFIX$/profile/espresso

  • No labels