...
- Entity Category, defined in RFC8409, is a metadata 'label' applied to identity providers or services which signal that they belong to the category which is described in the Entity Category specification. Metadata consumers which understand the Entity Category can alter their behaviour depending on the categories that the entity belongs to. Entity Categories may be used to signal commonly used attribute requirements, or commitment to a certain set of behavioural rules. Taking "Hide from Discovery" as an example: identity providers in this category do not want to be listed by default in discovery services; metadata consumers may be service providers that build their own discovery interfaces, or the metadata consumer may be a third party discovery service.
- Assurance Certification, defined in SAML V2.0 Identity Assurance Profiles Version 1.0, is a metadata label which can be applied to identity providers or services to signal that the entity conforms to the requirements of an identity assurance framework. The Assurance Certification can be self-asserted, or require validation by the registration authority (federation). An entity may conform to more than one Assurance Certification.
- Profiles, which define a standard to signal certain behaviour in a federated authentication transaction, and how to respond to such a request.
- Metadata Extension, provide an extention to existing metadata profiles.
- Frameworks, are currenlty basically assurance frameworks, which provide a structured means of describing or defining the main sources of assurance provided within the federation by the member entities or the federation itself.
Generally speaking, the information from the specifications is distributed in two ways:
- Entity metadata and/or
- As part of the transaction (e.g. in specific attribute values)
When a specification defines specific metadata elements to be be present, if is often required to have a protocol specific section in the specification. Not only is the technical format different (XML vs JSON), but there is also a difference in the way certain capabilities are expressed, e.g. Entity Categories vs Trustmarks, see later). When the specification only deals with 'on the wire' information, which is transmitted as part of the transaction, like e.g. attribute assurance, it if often much easier to adopt the specification to use in OIDC and OpenID federation, as often it suffices to just use the equivelent OIDC claim to transport the same values that were defined in tha SAML based specification.
OpenID Federation implementation of specification types
OpenID Federation shares many concepts with the existing SAML based federations as currently deployed in R&E. The basic entities (OP, RP and trusted third parties like TA or IA) and the interactions between these can all be represented in OpenID Federation in a similar fashion as these exist in a SAML R&E federation.
- Entity Category: Grouping In OpenID federation, a Trustmark is defined as the way to signal certain behaviour of entities is typically done via a:
- Trust Anchor or an Intermediate. All entities with similar behavious are members of the same intermediate (or trust anchor)
Trust Mark could also be used. A trust mark is created by a trust mark owner.- The trustmark owner must be trusted and listed as such by the federation TA
A Trust Mark may be self issued. A Trustmark is issued by a Trustmark Issuer, which in turn must be aknowledge in the Trust Anchor (metadata) to signal the Trustmark is part of the federation. A TA may set rules to enforce a Trustmark must be present in the entity metadata, which in turn leads to the mandatory requirement for entities to have the Trustmark before a trust chain can be esteblished. The presense of a Trustmark may also be used to filter OPs in support of the discovery process.
Trustmarks may be self issued, in which case they still need to be present at the TA. The Trustmark may be delegated to a Trustmark Owner. The Trustmark Owner may provide a delegation jwt to a Trustmark issuer so it can prove the legitimate issuance of Trustmarks.
One critical difference between Entity Categories and Trustmarks is that the same Trustmark cannot be both Self-issued as well as issued by a Trustmark Issuer.- Assurance Certification Signalling assurance certifications is may be done using so called Trust MarksTrustmarks.
- Profiles, signalling certain behaviour as part of a transaction is generally covered in the underlying standards like OpenID Connect and OAuth 2.0. The capablity for signalling is often available, however the semantics may need to be adopted
- Metadata Extension, provide an extention to existing metadata profiles is allowed in the OpenID Federation specification. For broad acceptance and implementation of an extention it may be needed to engage with the OpenID Foundation, e.g. via de RandE working group
- Frameworks, are currenlty currently basically assurance frameworks, which provide a structured means of describing or defining the main sources of assurance provided within the federation by the member entities or the federation itself.
Wallets
WIP
Table 1 provides an overview of the specifications that were evaluated, and identifies the areas in the specification that would need modification to adopt OIDC and OpenID federation. Because of the commonalities in the structure of the Personalized Access, the Anonymous Access and the Pseudonymous Access Entity Category, only the first one was extensivly evaluated, see Chapter 6. It was assumed similar modificatiosn will be required for the Anonymous Access and Pseudonymous Access specification.
Overview of findings
specification name | type | Applies to entity | Asserted by |
---|
Attribute profile | Entity behavioural rules | Attribute requirements | Level of Modification needed? | In scope for OpenIDFed | In scope for wallets | Attribute profile | SAML Specific Protocol requirements |
---|
Research and Scholarship (R&S) v1.3Personalized Access v.2 | Entity Category |
SP![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | - operated for the purpose of supporting research and scholarship interaction, collaboration or management, at least in part
- not be used for access to licensed content
- will not use attributes for purposes that fall outside of the service definition
| shared user identifierperson nameemail addressaffiliation (optional) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) |
![(question)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/help_16.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | - Use of SAML specific terms like IdP and SP
|
RFC8409.3.1 4.3.3Section 5 (moving mention of <md:RequestedAttribute>
mechanism to SAML 2.0 specific part of section 5 would already suffice- 5 (extention already possible)
- Section
|
6 ( and identifier handling)Section 7 (SAML example)Research and Scholarship (R&S) v1.3 | Entity Category | IdP | IdP | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | - will release attribute bundle attributes to R&S Service Providers for a significant subset of user polulation
- persistent, non-reassigned, non-targeted identifier
| - shared user identifier
- person name
- email address
- affiliation (optional)
| ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ![(question)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/help_16.svg) | ^^^
|
Hide From Discovery v.1 | Entity Category | IdP | IdP | ![(question)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/help_16.svg) | ![(question)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/help_16.svg) | Use of SAML specific terms like IdP and SPSection 5: SAML specific example- proof of successful authentication [ only ]
- signaling that they do not wish to receive personalized data
| (T) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) |
organization
affiliation (optional if no affiliation exists) | - Use of SAML specific terms like IdP and SP
- Section 4, RC1.1
- Section 5 (extention already possible)
- Section 7; SAML specific example. should probably move under 5.1.1
- Section 8; SAML specific example. should probably move under 5.1.1
|
Anonymous Access v.2 | Entity Category | IdP/OP | IdP/OP | ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) |
- release all required attributes in the bundle for a significant subset of user polulation
| (T) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) |
organization
affiliation (optional if no affiliation exists) | ^^^
|
Pseudonymous Access v.2 | Entity Category | SP/RP | Registrar | ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) | (T) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | - Use of SAML specific terms like IdP and SP
- Section 4, RC3
- Section 5 (extention already possible)
- Section 7; SAML specific example. should probably move under 5.1.1
- Section 8; SAML specific example. should probably move under 5.1.1
|
Pseudonymous Access v.2 | Entity Category | IdP/OP | IdP/OP |
![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | - release all required attributes in the bundle for a significant subset of user polulation
| ^^^ | Personalized Access v.2IdPUse of SAML specific terms like IdP and SPSection 4, RC3
(T) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | - RFC8409
- Section 4.3.1
- Section 4.3.3
- Section 5 (moving mention of
<md:RequestedAttribute> mechanism to SAML 2.0 specific part of section 5 would already suffice) - Section 6 (SAML specific example and identifier handling
|
Section 5 (extention already possible; specific example. should probably move under 5.1.1Section 8; SAML specific example. should probably move under 5.1.1Personalized Access v.2 | Entity Category | SP | Registrar | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ^^^ | Code of Conduct v.2 | Entity Category and Best Practice | Sirtfi v1 & v2 | Entity Attribute | SP | SP | |
Research and Scholarship (R&S) v1.3 | Entity Category | IdP/OP | IdP/OP | ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) | (T) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ^^^
|
Hide From Discovery v.1 | Entity Category | IdP/OP | IdP/OP |
| ![(question)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/help_16.svg) | ![(question)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/help_16.svg) |
| - Use of SAML specific terms like IdP and SP
- Section 5: SAML specific example
|
Assurance v.1 | Framework | IdP/OP | IdP/OP | ![(smile)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/smile.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | - Section 7 already discusses the use of the "eduperson_assurance" claim as the mechanism to provide assurance information in OIDC
|
MFA Profile v.1 | Profile |
|
| ![(smile)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/smile.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ![(question)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/help_16.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | - No changes needed, however has dependency on Security Contact Metadata Extension
- For use with wallets more context is needed
|
SFA Profile v.1 | Profile |
|
| ![(smile)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/smile.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ![(question)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/help_16.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | - No changes needed, however has dependency on Security Contact Metadata Extension
- For use with wallets more context is needed
|
Sirtfi v1 & v2 | Assurance Certification | SP/RP | Registrar | ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) | (T) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) |
|
|
Sirtfi v1 & v2 | Assurance Certification | IdP/OP | IdP/OP | ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) | (T) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) |
|
|
Security Contact | Metadata Extension | IdP/OP, SP/RP | IdP/OP, SP/RP | ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) | ![(tick)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/check.svg) |
| - No OIDC or OpenID Federation specification present.
- Requires extention of OIDC Metadata model
|
Legenda for relevance column:
Under investigation;
Not relevent;
Relevant
Updates ; (T) Trustmark required
Indication of required changed:
No changes required;
Minor updates to wording required; ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg)
Significant updates to wording required; ![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg)
![(warning)](/s/p416ui/8804/1v70iay/_/images/icons/emoticons/warning.svg)
Significant updates to wording and/or implementation required
Detailed discussion
Research and Scholarship (R&S) v1.3
...
Personalized Access v.2