...
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 the SAML based specification.
...
REFEDs has defined a set of functionally similar specifications which began with "Research and Scholarship" and now also includes , "Anonymous Access", "Pseudonoymous Access" , and "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 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 veted by FedOps, whereas the IdP version is self issued). This leads 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.Is seems like a good idea to include the definition of a personalized scope to streamline the exchange of personal data
- 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 techncial infrastructure which would have to be part of the actual authentication transactions.
- Is seems like a good idea to include the definition of a personalized scope to streamline the exchange of personal data
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.
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 relevent to the transaction at hand. In a wallet ecosystem, it might be relevant to transport this MFA or SFA information as part 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 reqire a specification similar to the existing RAF, or perhaps RAF may be extended to include this information.