You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

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

REFEDs specifications

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

specification nametypeURIdoisupporting material
Research and Scholarship (R&S) v1.3Entity Categoryhttp://refeds.org/category/research-and-scholarship  
DOI
https://wiki.refeds.org/display/ENT/Research+and+Scholarship
Hide From Discovery v.1Entity Categoryhttp://refeds.org/category/hide-from-discovery
DOI

https://wiki.refeds.org/display/ENT/Hide+From+Discovery
Anonymous Access v.2Entity Categoryhttps://refeds.org/category/anonymous
DOI 
https://wiki.refeds.org/x/aQA2B
Pseudonymous Access v.2Entity Categoryhttps://refeds.org/category/pseudonymous
DOI
https://wiki.refeds.org/x/aQA2B
Personalized Access v.2Entity Categoryhttps://refeds.org/category/personalized
DOI 
https://wiki.refeds.org/x/aQA2B
Code of Conduct v.2Entity Category and Best Practicehttps://refeds.org/category/code-of-conduct/v2
DOI
https://refeds.org/category/code-of-conduct/
Sirtfi v1 & v2Entity Attribute

https://refeds.org/sirtfi

https://refeds.org/sirtfi2

DOI
https://wiki.refeds.org/display/SIRTFI/SIRTFI+Home





MFA Profile v.1Profilehttps://refeds.org/profile/mfa
DOI
https://wiki.refeds.org/display/PRO/MFA
SFA Profile v.1Profilehttps://refeds/org/profile/sfa
DOI
https://wiki.refeds.org/display/PRO/SFA
Error Handling v.1Profilehttps://refeds.org/specifications/errorurl-v1
DOI
https://wiki.refeds.org/display/PRO/Error+Handling+URL+Profile





Security ContactMetadata Extensionhttp://refeds.org/metadata/contactType/security
DOI
https://wiki.refeds.org/display/SIRTFI/SIRTFI+Home





Baseline Expectations v.1Frameworkhttps://refeds.org/baseline-expectations
DOI
https://wiki.refeds.org/display/BASE
Assurance v.1Frameworkhttps://refeds.org/assurance
DOI
https://wiki.refeds.org/display/ASS/Assurance+Home

Specification types

REFEDs identify 5 types of specifications:

  • Entity Category, defined in RFC8409, are metadata 'labels' applied to either identity providers or services which may be used under certain conditions, as described in the Entity Category specification, to indicate a grouping of entities. Entity Categories may be used to signal commonly used attribute requirements, or commitment to a certain set of behavioural rules.
  • Entity Attribute are metadata labels applied to either identity providers or services to signal assurance certifications.
  • 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.

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: Grouping of entities is typically done via a:
    • Trust Anchor or an Intermediate. All entities with similar behavious are members of the same intermediate (or trust anchor)
    • Trust Mark could also be used. A trust mark is created by a trust mark owner (
      • A Trust Mark may be self issued.
  • Entity Attribute Signalling assurance certifications is done using so called Trust Marks.
  • Profiles, signalling certain behaviour as part of a transaction is generally covered in the underlying standards like OpenID Connect and OAuth2. The capablity for signalling is often available, however the semantics may need to be adopted
  • Metadata Extension, provide an extention to existing metadata profiles is allowed in the OpenID Federation specification. For broad acceptance and implementation of an extention it may be needed to engage with the OpenID Foundation, e.g. via de RandE working group
  • 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.


Wallets


Overview of findings

specification nametypeApplies
to entity
Asserted
by
Attribute
profile
Entity behavioural rulesAttribute requirements

In scope for OpenIDFed

In scope for wallets

SAML Specific
Protocol  requirements
Research and Scholarship (R&S) v1.3Entity CategorySPRegistrar(tick)
  • operated for the purpose of supporting research and scholarship interaction, collaboration or management, at least in part
  • not be used for access to licensed content 
  • will not use attributes for purposes that fall outside of the service definition
  • shared user identifier
  • person name
  • email address
  • affiliation (optional)
(tick)(question)
  • 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.3Entity CategoryIdPIdP(tick)
  • will release attribute bundle attributes to R&S Service Providers for a significant subset of user polulation
  • persistent, non-reassigned, non-targeted identifier
  • shared user identifier
  • person name
  • email address
  • affiliation (optional)
(tick)(question)^^^
Hide From Discovery v.1Entity CategoryIdPIdP


(question)(question)
  • Use of SAML specific terms like IdP and SP
  • Section 5: SAML specific example
Anonymous Access v.2Entity CategorySPRegistrar(tick)
  • proof of successful authentication [ only ]
  • signaling that they do not wish to receive personalized data
  • organization
  • affiliation (optional if no affiliation exists)


  • Section 4, RC3
  • Section 5 (extention already possible)
  • Section 7
  • Section 8
Anonymous Access v.2Entity CategoryIdPIdP(tick)
  • release all required attributes in the bundle for a significant subset of user polulation
  • organization
  • affiliation (optional if no affiliation exists)


^^^
Pseudonymous Access v.2Entity CategorySPRegistrar(tick)



  • Section 4, RC3
  • Section 5 (extention already possible)
  • Section 7
  • Section 8
Pseudonymous Access v.2Entity CategoryIdPIdP(tick)
  • release all required attributes in the bundle for a significant subset of user polulation




Personalized Access v.2Entity CategorySPRegistrar(tick)




Code of Conduct v.2Entity Category and Best Practice







Sirtfi v1 & v2Entity AttributeSPSP





Legenda for relevance column: (question) Under investigation (error) Not relevent (tick) Relevant (warning) Updates to wording and/or implementation required

Detailed discussion

Research and Scholarship (R&S) v1.3

  • The Research and Scholarship (R&S) v1.3 specification describes an Entity category which is applied to both IdPs and SPs.
  • The SP compliance to the specification is asserted by the Registrar.
  • The specification includes an attribute profile which defines the following attributes:
    • shared user identifier
    • person name
    • email address
    • affiliation (optional)
  • No labels