...
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 excercise 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 email addressesstrings. 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.
- Is It seems like a good idea to include the definition of a personalized scope to streamline the exchange of personal data
...
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 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.
...
The SIRTFI specification leverages metadata to signal ciompliance compliance for both SPs/RP as well as IdP/OP. When discussing the SERTFI 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 email addressesstrings. 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 techincal technical infrastructure which would have to be part of the actual authentication transactions.
...