...

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 meay may be required to translate between not just technical credentials, but also policy and trust frames.

...

• 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

...

Legenda for relevance column: Under investigation; Not relevent; 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

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

Personalized Access v.2

REFEDs has defined a set of similar specifications which began with "Research and Scholarship" and now also includes "Anonymous Access", "Pseudonoymous Access", "Personalized Access". All of these specfications 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 excersize 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 use of entity labels, "Trustmarks" in OpenID Federation, is subject to specific rules as layed out in the 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 veted by FedOps, whereas the IdP version is self issued). This leads 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.
• Is seems like a good idea to include the definition of a personalized scope to streamline the exchange of personal data