1. Introduction

The research and education sector has over the past decades developed a global identity federation ecosystem which has simplified access to content, services and resources for their community. The eduGAIN interfederation comprises over 80 national federations connecting more than 8,000 Identity and Service Providers. On a national level even more services and institutions are connected. The sector has been able to achive this by creating a highly interoperable ecosystem, where both a high level of technical, as well as policy and trust interoperability has been accomplished, through the joined implementation of various specifications. The joined journey of establishing this ecosystem has enabled the emergance of a global research and education trust and identity comunity with strong bonds and decades of experience in deploying and operating identity federation at scale.

REFEDs, the Research and Education FEDerations group, has been instrumental in providing an open meeting place for articulating the mutual needs of research and education identity federations worldwide. Over the years, REFEDS has addressed issues and topics based on the interests and requirements of its participants. This includes mostly policy, but also some technical and outreach topics in areas such as interfederation, privacy, assurance, relationships with partner communities, marketing, and support of emerging federations.

While REFEDs as such has no bias towards a specific technical implementation, the fact that the SAML 2.0 specification is currently the dominant protocol in identity federation in R&E has had some impact on various specifications created by REFEDs. This ranges for protocol specific sections, to assumption on how a specification would be implemented operationally. The rise of protocols like OpenID Connect, OpenID Federation and the emergence of decentralized, wallet based ecosystems requires a revisit of the specifications. Not only should it be investigated in what way the specifications may be implemented in these protocols, in addition we must assume a multi-protocol ecosystem will emerge and exist for several years to come. This means the specifications may also need to take into account how to go between protocols as it may be required to translate between not just technical credentials, but also policy and trust frames.

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 still being developed, the statments and assumptions on how REFEDs specification may be relevant should be considered speculative. 

2. REFEDs specifications

source: https://refeds.org/specifications (Nov 2023) 

specification name	type	URI	doi	supporting material
Research and Scholarship (R&S) v1.3	Entity Category	http://refeds.org/category/research-and-scholarship		https://wiki.refeds.org/display/ENT/Research+and+Scholarship
Hide From Discovery v.1	Entity Category	http://refeds.org/category/hide-from-discovery		https://wiki.refeds.org/display/ENT/Hide+From+Discovery
Anonymous Access v.2	Entity Category	https://refeds.org/category/anonymous		https://wiki.refeds.org/x/aQA2B
Pseudonymous Access v.2	Entity Category	https://refeds.org/category/pseudonymous		https://wiki.refeds.org/x/aQA2B
Personalized Access v.2	Entity Category	https://refeds.org/category/personalized		https://wiki.refeds.org/x/aQA2B
Code of Conduct v.2	Entity Category and Best Practice	https://refeds.org/category/code-of-conduct/v2		https://refeds.org/category/code-of-conduct/
Sirtfi v1 & v2	Assurance Certification	https://refeds.org/sirtfi https://refeds.org/sirtfi2		https://wiki.refeds.org/display/SIRTFI/SIRTFI+Home
MFA Profile v.1	Profile	https://refeds.org/profile/mfa		https://wiki.refeds.org/display/PRO/MFA
SFA Profile v.1	Profile	https://refeds/org/profile/sfa		https://wiki.refeds.org/display/PRO/SFA
Error Handling v.1	Profile	https://refeds.org/specifications/errorurl-v1		https://wiki.refeds.org/display/PRO/Error+Handling+URL+Profile
Security Contact	Metadata Extension	http://refeds.org/metadata/contactType/security		https://wiki.refeds.org/display/SIRTFI/SIRTFI+Home
Baseline Expectations v.1	Framework	https://refeds.org/baseline-expectations		https://wiki.refeds.org/display/BASE
Assurance v.1	Framework	https://refeds.org/assurance		https://wiki.refeds.org/display/ASS/Assurance+Home

3. Specification types

REFEDs identify 5 types of specifications:

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

3.1. 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: In OpenID federation, a Trustmark is defined as the way to signal certain behaviour of entities. A Trustmark is issued by a Trustmark Issuer, which in turn must be acknowledged in the Trust Anchor (metadata) to signal the Trustmark is part of the federation. A TA may set rules to enforce that 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 established. The presence 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 owned by a Trustmark Owner outside of the federation and delegate issuance. 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 may be done using so called Trustmarks.
  
• Profiles, signalling certain behaviour as part of a transaction is generally covered in the underlying standards like OpenID Connect and OAuth 2.0 by e.g. scopes and claims. The capability for signalling is often available, however the semantics may need to be adopted
• Metadata Extension, provide an extension to existing metadata profiles is allowed in the OpenID Federation specification. For broad acceptance and implementation of an extension it may be needed to engage with the OpenID Foundation, e.g. via de RandE working group
• Frameworks, are 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.

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 extensively evaluated, see Chapter 6. It was assumed similar modifications will be required for the Anonymous Access and Pseudonymous Access specification.

4. Overview of findings

specification name	type	Applies to entity	Asserted by	Level of Modification needed?	In scope for OpenIDFed	In scope for wallets	Attribute profile	SAML Specific Protocol  requirements
Personalized Access v.2	Entity Category	IdP/OP	Registrar		(T)			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
Personalized Access v.2	Entity Category	SP/RP	Registrar		(T)			^^^
Anonymous Access v.2	Entity Category	SP/RP	Registrar		(T)			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		(T)			^^^
Pseudonymous Access v.2	Entity Category	SP/RP	Registrar		(T)			Use of SAML specific terms like IdP and SP Section 4, RC3 Section 5 (extension 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		(T)			^^^
Research and Scholarship (R&S) v1.3	Entity Category	SP/RP	Registrar		(T)			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 7 (SAML example)
Research and Scholarship (R&S) v1.3	Entity Category	IdP/OP	IdP/OP		(T)			^^^
Hide From Discovery v.1	Entity Category	IdP/OP	IdP/OP					Use of SAML specific terms like IdP and SP Section 5: SAML specific example
Assurance v.1	Framework	IdP/OP	IdP/OP					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							No changes needed, however has dependency on Security Contact Metadata Extension For use with wallets more context is needed
SFA Profile v.1	Profile							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		(T)
Sirtfi v1 & v2	Assurance Certification	IdP/OP	IdP/OP		(T)
Security Contact	Metadata Extension	IdP/OP, SP/RP	IdP/OP, SP/RP					No OIDC or OpenID Federation specification present. Requires extension of OIDC Metadata model

Legend for relevance column: Under investigation; Not relevant; Relevant; (T) Trustmark required
Indication of required changed: No changes required; Minor updates to wording required; Significant updates to wording required; Significant updates to wording and/or implementation required

5. Detailed discussion

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 equivalent OIDC claim to transport the same values that were defined in the SAML based specification.

5.1. Personalized Access v.2

REFEDs has defined a set of functionally similar specifications "Research and Scholarship", "Anonymous Access", "Pseudonoymous Access" and "Personalized Access". All of these specifications share the fact that they express the capabilities in entity metadata. To investigate the potential impact of introducing the use of OIDC and  OpenID Federation, the Incubator has made an in depth analysis of the impact on "Personalized Access Entity Category". The document which was created is not intended as a proposal to replace the existing specification, but rather as a practical exercise to asses the impact. The document can be found here: https://github.com/surfnet-niels/REFEDs-specifications/blob/main/personalized.md
Generally speaking the following was noted:

• The layout of the existing specifications should be adopted significantly to allow for incorporating new protocols.
• Many sections, even if these do not specifically reference an implementation, make use of SAML specific jargon. This includes the name of the thing itself: an Entity Category is defined in the SAML specification.

• The OIDC specification supports the concept of contact details, but only as a simple multivalued list of strings. In the SAML version of the specification a more fine grained methodology is used, where technical, administrative and support contact details are identifiable. To resolve this issue, the proposal in github suggests a new claim, "contacts_detailed", supports the same granularity as is used in the SAML implementation of the specification.

• The use of entity labels, "Trustmarks" in OpenID Federation, is subject to specific rules as layed out in the OID Fed specification. As such it is not possible to have the same Trustmark exist both as a self-issued and at the same time as a trustmark issued by a trustmark issuer, which is what the current specification suggests (SPs and IdP may both publish support for the entity category, however the SP version is vetted by FedOps, whereas the IdP version is self issued). This might lead to the need to have different trustmark identifiers per protocol. This is probable not optimal as it may lead to ambiguity in the implementation of the same specification between protocols.

• OpenID Federation has a well developed mechanism to delegate the issuance and ownership of Trustmarks. These capabilities may allow REEFDs to be owner of the relevant Trustmarks without the need to implement a technical infrastructure which would have to be part of the actual authentication transactions.
• It seems like a good idea to include the definition of a personalized scope to streamline the exchange of personal data

5.2. Assurance Framework

The assurance profile already has a provision (section 7) on how to use the specification with OIDC. All statements which are part of this specification are expressed as claim values.

5.3. MFA and SFA framework

The Multi- and Single Factor Authentication profile express all statements at transaction time. Both specifications already describe how to use these both in the SAML and in OIDC. For both SAML and OIDC the specification is relevant to the transaction at hand. In a wallet ecosystem, it might be relevant to transport this MFA or SFA information as part of the credentials statement made by a wallet, as such information refers to the LoA of the credentials stored in the wallet. To describe such information, it may require a specification similar to the existing RAF, or perhaps RAF may be extended to include this information.

5.4. SIRTFI

The SIRTFI specification leverages metadata to signal compliance for both SPs/RP as well as IdP/OP. When discussing the SIRTFI specification the following was noted:

• The layout of the existing specifications should be adopted significantly to allow for incorporating new protocols.
• Many sections, even if these do not specifically reference an implementation, make use of SAML specific jargon. This includes the name of the thing itself: an Entity Category is defined in the SAML specification.

• The OIDC specification supports the concept of contact details, but only as a simple multivalued list of strings. The SIRTFI specification mandates the presence of a security contact, as described in the Security Contact specification. To resolve this issue, a new claim, "contacts_detailed", could support the required granularity that is needed.

• The use of entity labels, "Trustmarks" in OpenID Federation, is subject to specific rules as layed out in the OID Fed specification. As such it is not possible to have the same Trustmark exist both as a self-issued and at the same time as a trustmark issued by a trustmark issuer, which is what the current specification suggests (SPs and IdP may both publish support for the entity category, however the SP version is vetted by FedOps, whereas the IdP version is self issued). This might lead to the need to have different trustmark identifiers per protocol. This is probable not optimal as it may lead to ambiguity in the implementation of the same specification between protocols.

• OpenID Federation has a well developed mechanism to delegate the issuance and ownership of Trustmarks. These capabilities may allow REEFDs to be owner of the relevant Trustmarks without the need to implement a technical infrastructure which would have to be part of the actual authentication transactions.