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 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

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

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

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:

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:

Appendix B: Examples on assurance values

A university who guarantees that its faculty members

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