...
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.
Table of Contents
2.2. Identity proofing and credential issuance, renewal and replacement
2.3. Attribute quality and freshness
5. Representation on federated protocols
5.1. Security Assertion Markup Language 2.0 (SAML)
Appendix A: Local enterprise -- Good enough for internal systems
Appendix B: Examples on assurance values
1. Terms and definitions
Term | Definition |
Credential | 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].
...
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.
Value | Description |
$PREFIX$/ID/unique | 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.
...
The values are mutually exclusive. A CSP MAY assert one of them but MUST NOT assert more than one.
Value | Description |
$PREFIX$/ID/eppn-unique-no-reassign | eduPersonPrincipalName value has the Unique-1, Unique-2 and Unique-3 properties. |
$PREFIX$/ID/eppn-unique-reassign-1y | 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
...
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.
Value | Description |
$PREFIX$/IAP/low | Identity proofing and credential issuance, renewal, and replacement qualify to any of
Example: self-asserted identity together with verified e-mail address, following sections sections 5.1.2-5.1.2.9 and section 5.1.3 of [Kantara SAC]. |
$PREFIX$/IAP/medium | Identity proofing and credential issuance, renewal, and replacement qualify to any of
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]. |
$PREFIX$/IAP/high | Identity proofing and credential issuance, renewal, and replacement qualifies to any of
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:
Value | Description |
$PREFIX$/IAP/local-enterprise | 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
...
The values are hierarchical. A CSP which asserts $PREFIX$/ATP/ePA-1d MUST assert also $PREFIX$/ATP/ePA-1m for a given user.
Value | Description |
$PREFIX$/ATP/ePA-1m | eduPersonAffiliation, eduPersonScopedAffiliation and eduPersonPrimaryAffiliation attributes (if populated and released to the RP) reflect user’s departure within 31 days time |
$PREFIX$/ATP/ePA-1d | 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
...
A CSP qualifies to a profile if it asserts (and complies with) all the values marked as ‘X’ in the column.
Value | Cappuccino | Espresso |
$PREFIX$ | X | X |
$PREFIX$/ID/unique | X | X |
$PREFIX$/ID/eppn-unique-no-reassign | ||
$PREFIX$/ID/eppn-unique-reassign-1y | ||
$PREFIX$/IAP/low | X | X |
$PREFIX$/IAP/medium | X | X |
$PREFIX$/IAP/high | X | |
$PREFIX$/IAP/local-enterprise | ||
$PREFIX$/ATP/ePA-1m | X (*) | X (*) |
$PREFIX$/ATP/ePA-1d |
(*) The CSP can omit this requirement if it doesn’t populate and release the attribute values defined in section 2.3 for this user.
...
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
eduPerson | Internet2/MACE. eduPerson Object Class Specification (201602). http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html |
eIDAS LoA | 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. http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:JOL_2015_235_R_0002 |
ePSA Comparison | Cormack, A., Linden, M. REFEDs ePSA usage comparison, version 0.13. https://blog.refeds.org/wp-content/uploads/2015/05/ePSAcomparison_0_13.pdf |
IGTF | Groep, D (editor). IGTF Levels of Authentication Assurance, version 1.0. https://www.igtf.net/ap/authn-assurance/ |
Kantara SAC | Kantara Initiative. Kantara Identity Assurance Framework. KIAF-1420 Operational -63r2 Service Assessment Criteria. Version 1.0. Publication Date 2018-03-21. https://kantarainitiative.org/confluence/display/LC/Identity+Assurance+Framework |
OASIS SAML | Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS Standard. 15 March 2005. |
OASIS SIA | SAML V2.0 Subject Identifier Attributes Profile Version 1.0. Committee Specification Draft 02 / Public Review Draft 02. 10 April 2018. |
REFEDS OIDCre | OpenID Connect for Research and Education Working Group. Mapping SAML attributes to OIDC Claims. Referenced 9 February 2018. https://wiki.refeds.org/display/GROUPS/Mapping+SAML+attributes+to+OIDC+Claims |
RFC2119 | Bradner, S. Key words for use in RFCs to Indicate Requirement Levels. RFC2119. https://www.ietf.org/rfc/rfc2119.txt |
X.1254 | International Telecommunication Union. Series X. Data Networks, Open System Communication and Security. Cyberspace security – Identity management. Entity authentication assurance framework. Standard X.1254.https://www.itu.int/rec/T-REC-X.1254 |
Appendix A: Local enterprise -- Good enough for internal systems
...