...
This document provides a first assesment on how the current REFEDs specifications (Nov 2023) may be leveraged in an OpenID Federation (Draft 31) based federation and in a wallet ecosystem based on OpenID Federation and the OpenID4VC specifications. For the latter it should be noted that as this ecosystem and its standards are stll being developed, the statments and assumptions on how REFEDs specification may be relevant should be considered speculative.
REFEDs specifications
source: https://refeds.org/specifications (Nov 2023)
...
Specification types
REFEDs identify 4 5 types of specifications:
- Entity Category, defined in RFC8409, are metadata 'labels' applied to either identity providers or services which may be used under certain conditions, as described in the Entity Category specification, to indicate a grouping of entities. Entity Categories may be used to signal commonly used attribute requirements, or commitment to a certain set of behavioural rules.
- Entity Attribute are metadata labels applied to either identity providers or services to signal assurance certifications.
- 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.
OpenID Federation
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 of entities is typically done via a Trust Anchor or an Intermediate.
- Entity Attribute Signalling assurance certifications is done using so called Trust Marks.
- Profiles, signalling certain behaviour as part of a transaction is generally covered in the underlying standards like OpenID Connect and OAuth2. 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 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
Overview of findings
specification name | type | Applies to entity | Asserted by | Attribute profile | Entity behavioural rules | Attribute requirements | In scope for OpenIDFed | In scope for wallets | SAML Specific Protocol requirements |
---|---|---|---|---|---|---|---|---|---|
Research and Scholarship (R&S) v1.3 | Entity Category | SP | Registrar |
|
|
|
| |||||||||
Research and Scholarship (R&S) v1.3 | Entity Category | IdP | IdP |
|
| ^^^ | |||
Hide From Discovery v.1 | Entity Category | IdP | IdP |
| |||||
Anonymous Access v.2 | Entity Category | SP | Registrar |
|
|
| |||
Anonymous Access v.2 | Entity Category | IdP | IdP |
|
| ^^^ | |||
Pseudonymous Access v.2 | Entity Category | SP | Registrar |
| |||||
Pseudonymous Access v.2 | Entity Category | IdP | IdP |
| |||||
Personalized Access v.2 | Entity Category | SP | Registrar | ||||||
Code of Conduct v.2 | Entity Category and Best Practice | ||||||||
Sirtfi v1 & v2 | Entity Attribute | SP | SP |
Legenda for relevance column: Under investigation
Not relevent
Relevant
Updates to wording and/or implementation required
Detailed discussion
Research and Scholarship (R&S) v1.3
- The Research and Scholarship (R&S) v1.3 specification describes an Entity category which is applied to both IdPs and SPs.
- The SP compliance to the specification is asserted by the Registrar.
- The specification includes an attribute profile which defines the following attributes:
- shared user identifier
- person name
- email address
- affiliation (optional)