A first attempt at mapping REFEDs Identity federation trust and trustmarks to an OpenID Federation based wallet ecosystem (WIP!)

REFEDs current list (Nov 2023) - https://refeds.org/specifications

specification name	type	URI	doi	supporting material	Relevance
Research and Scholarship (R&S) v1.3	Entity Category	http://refeds.org/category/research-and-scholarship		https://wiki.refeds.org/display/ENT/Research+and+Scholarship
Hide From Discovery v.1	Entity Category	http://refeds.org/category/hide-from-discovery		https://wiki.refeds.org/display/ENT/Hide+From+Discovery
Anonymous Access v.2	Entity Category	https://refeds.org/category/anonymous		https://wiki.refeds.org/x/aQA2B
Pseudonymous Access v.2	Entity Category	https://refeds.org/category/pseudonymous		https://wiki.refeds.org/x/aQA2B
Personalized Access v.2	Entity Category	https://refeds.org/category/personalized		https://wiki.refeds.org/x/aQA2B
Code of Conduct v.2	Entity Category and Best Practice	https://refeds.org/category/code-of-conduct/v2		https://refeds.org/category/code-of-conduct/
Sirtfi v1 & v2	Entity Attribute	https://refeds.org/sirtfi https://refeds.org/sirtfi2		https://wiki.refeds.org/display/SIRTFI/SIRTFI+Home
MFA Profile v.1	Profile	https://refeds.org/profile/mfa		https://wiki.refeds.org/display/PRO/MFA
SFA Profile v.1	Profile	https://refeds/org/profile/sfa		https://wiki.refeds.org/display/PRO/SFA
Error Handling v.1	Profile	https://refeds.org/specifications/errorurl-v1		https://wiki.refeds.org/display/PRO/Error+Handling+URL+Profile
Security Contact	Metadata Extension	http://refeds.org/metadata/contactType/security		https://wiki.refeds.org/display/SIRTFI/SIRTFI+Home
Baseline Expectations v.1	Framework	https://refeds.org/baseline-expectations		https://wiki.refeds.org/display/BASE
Assurance v.1	Framework	https://refeds.org/assurance		https://wiki.refeds.org/display/ASS/Assurance+Home

Legenda for relevance column: Under investigation Not relevent Relevant Updates to wording and/or implementation required

REFEDs identify 4 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 of the federation itself.

• An entity category may be used to expres a certain behaviour from the entity, or compliance to certain commonly understood policy. For example in R&S: "Service Providers that are operated for the purpose of supporting research and scholarship interaction, collaboration or management, at least in part". Such Entity Categories may be very usefull as these can be used to inform issuers and user about the verifiers intentions. If an entity category is asserted by the

The Entity Category capability of grouping of entities which have similar hehaviour, goal or purpose seems like a usefull capability

Research and Scholarship

Hide From Discovery

The discovery process, and hence the user flow for an issuer is fundementally different from discovery as used in multilateral SAML federations. Hence this specification is deemed not relevant

Code of Conduct

specification name	type	Applies to	Asserted by	Attribute profile	Entity behavioural rules	Attribute requirements	Protocol Specific requirements
Research and Scholarship (R&S) v1.3	Entity Category	SP	Registrar		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)	Section 4.3.1 Section 4.3.3 Section 5 (moving mention of <md:RequestedAttribute> mechanism to SAML 2.0 specificpart of section 5 would already suffice) Section 6 (SAML specific example and identifier handling) Section 7 (SAML example)
Research and Scholarship (R&S) v1.3	Entity Category	IdP	IdP		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)	^^^
Hide From Discovery v.1	Entity Category	IdP	IdP				Use of SAML specific terms like IdP and SP Section 5: SAML specific example
Anonymous Access v.2	Entity Category	SP	Registrar		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.2	Entity Category	IdP	IdP		release all required attributes in the bundle for a significant subset of user polulation	organization affiliation (optional if no affiliation exists)	^^^
Pseudonymous Access v.2	Entity Category	SP	Registrar				Section 4, RC3 Section 5 (extention already possible) Section 7 Section 8
Pseudonymous Access v.2	Entity Category	IdP	IdP		release all required attributes in the bundle for a significant subset of user polulation
Personalized Access v.2	Entity Category	SP	Registrar
Code of Conduct v.2	Entity Category and Best Practice
Sirtfi v1 & v2	Entity Attribute	SP	SP