Table of Contents |
---|
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.
...
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.
SIRTFI
The SIRTFI specification leverages metadata to signal ciompliance for both SPs/RP as well as IdP/OP. When discussing the SERTFI 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 adresses. 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 veted 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 techncial infrastructure which would have to be part of the actual authentication transactions.