Publication History
Overview
| Version History | v.1 published 13 March 2021 v.2 published 13 February 2023 (this version) |
| Reference pdf | https://zenodo.org/record/7684488/files/ENTCAT-PSEUD-v2.pdf |
| DOI |  |
| License | This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. |
| Supporting Material | https://wiki.refeds.org/x/aQA2B |
Overview
Research and Education Federations are invited to use the REFEDS Pseudonymous Access Entity Category with their members to support the release of attributes to Service Providers meeting the requirements described below.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [BCP14].
This definition is written in compliance with the Entity Category SAML Entity Metadata Attribute Types specification [RFC8409]; this specification may be extended to reference other protocol-specific formulations as circumstances warrant.
An FAQ for the Entity Category has been made available to help deployments [FAQ].
1. Definition
Candidates for the Pseudonymous Access Entity Category are Service Providers that offer a level of service based on proof of successful authentication and offer personalization based on a pseudonymous user identifier. The Service Provider must be able to effectively demonstrate this need to their federation registrar (normally the Service Provider’s home federation) and demonstrate their compliance with regulatory requirements concerning personal data through a published Privacy Notice.
None of the attributes in this entity category are specifically intended to provide authorization information. See section 6 for a discussion of this use case.
Identity Providers may indicate support for this Entity Category to facilitate discovery and improve the user experience at Service Providers. Self-assertion is the typical approach used, but this is not the only acceptable method.
2. Syntax
The following URI is used as the attribute value for the Entity Category and Entity Category Support attribute:
https://refeds.org/category/pseudonymous3. Semantics
By asserting a Service Provider to be a member of this Entity Category, a federation registrar claims that:
- (SE1) The Service Provider has requested assignment of the Category and complies with this entity category’s registration criteria.
- (SE2) The Service Provider’s request to be assigned the Pseudonymous Access Entity Category has been reviewed against the provided REFEDS [Guidelines] and approved by the federation registrar.
By registering for this Entity Category, a Service Provider has agreed to the registration criteria as defined in Section 4.
By asserting support for this Entity Category, Identity Providers are indicating that they will release attributes to Service Providers that also assert this category.
4. Registration Criteria
When a Service Provider’s federation registers the Service Provider in the Entity Category, the federation registrar MUST perform at least the following checks:
- (RC1) The service has a proven and documented need for the pseudonymous information that forms the attribute bundle for this entity category.
- (RC2) The Service Provider has committed to data minimisation and will not use the attributes for purposes other than as described in their request.
- (RC3) Ensure that the service meets the following technical requirements:
- (RC3.1) The Service Provider provides an <mdui:DisplayName>, <mdui:InformationURL>, and <mdui:PrivacyStatementURL> in metadata. Including an English language version (i.e., xml:lang=”en”) is RECOMMENDED.
- (RC3.2) The Service Provider provides one or more contacts in metadata.
These are the requirements to assert this entity category; any change MUST be reported by the Service Provider to the federation registrar. The federation registrar MUST remove the Entity Category if the Service Provider indicates a change in conformance. The federation registrar MUST have other remediation procedures to address a lack of compliance with these requirements.
5. Service Provider Requirements
The mechanism by which this entity category provides for consistent attribute release is through the definition of a set of commonly supported and consumed attributes. The attributes chosen represent a privacy baseline such that further minimization achieves no particular benefit for applicable services. Thus, the minimal disclosure principle is designed into this category.
The use of the <md:RequestedAttribute> mechanism supported by SAML metadata is outside the scope of this category, and may co-exist with it in deployments as desired, subject to this specification’s requirements being met.
5.1 Required Attributes
The entity category attribute bundle consists (abstractly) of the following data elements:
- organization
- pseudonymous pairwise user identifier
- affiliation
- assurance
These abstract elements are bound to protocol-specific definitions in the following subsection(s) and additional bindings may be added in the future.
It is understood that not every subject can necessarily be associated with values for every attribute. For example, some users may have no formal affiliation with the issuing organization. In such cases, it is expected that those attribute(s) may not be provided. The designation that all these attributes are required is a general obligation and not specific to a given subject.
With regard to assurance, the REFEDS Assurance Framework [RAF] is REQUIRED as a source of values, but other frameworks and their values are permitted. The requirement to support the REFEDS Assurance Framework implies that at least one value, ‘https://refeds.org/assurance‘ MUST be supplied, but no others are specifically required unless the IdP deems them to be applicable.
Identity Providers are not expected or required to alter their business processes or to provide any particular assurance level for their subjects, but rather are required to communicate what they do provide or other applicable information as appropriate.
5.1.1 SAML 2.0
When the SAML 2.0 protocol is used, the following SAML attributes make up the required attribute set defined abstractly above. In all cases, the defined NameFormat is urn:oasis:names:tc:SAML:2.0:attrname-format:uri
- organization is defined to be:
- schacHomeOrganization [SCHAC]
- Attribute Name: urn:oid:1.3.6.1.4.1.25178.1.2.9
- schacHomeOrganization [SCHAC]
- pseudonymous pairwise user identifier is defined to be:
- pairwise-id [SAMLSubId]
- Attribute Name: urn:oasis:names:tc:SAML:attribute:pairwise-id
- pairwise-id [SAMLSubId]
- affiliation is defined to be:
-
- eduPersonScopedAffiliation [eduPerson]
- Attribute Name: urn:oid:1.3.6.1.4.1.5923.1.1.1.9
- eduPersonScopedAffiliation [eduPerson]
-
- assurance is defined to be:
-
- eduPersonAssurance [eduPerson]
- Attribute Name: urn:oid:1.3.6.1.4.1.5923.1.1.1.11
- eduPersonAssurance [eduPerson]
-
The specific naming and format of the attributes above is guided by the [SAMLAttr] and [SAMLSubId] profiles.
6.Authorization
None of the attributes defined in Section 5 are suitable for accurately signaling access authorization; signaling authorization is out of scope for this entity category. While they are often used as approximations, this inevitably denies access to authorized users and permits access to unauthorized users.
A companion document discussing the federated authorization problem and suggested practices can be found at [FederatedAuthorization].
7. Deployment Guidance for Service Providers
Service Providers SHOULD rely on the bundle of attributes defined in Section 5, but MAY ask for, or even require, other information as needed for additional purposes, via mechanisms that are outside the scope of this specification.
A common example would be a requirement for indicating authorization to access a service (see Section 6).
A Service Provider that conforms to this entity category would exhibit the following entity attribute in SAML metadata:
<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
<saml:Attribute
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="http://macedir.org/entity-category">
<saml:AttributeValue>https://refeds.org/category/pseudonymous</saml:AttributeValue>
</saml:Attribute>
</mdattr:EntityAttributes>
8.Deployment Guidance for Identity Providers
An Identity Provider indicates support for this entity category by exhibiting the entity attribute in its metadata. Such an Identity Provider MUST, for a significant subset of its user population, release all required attributes in the bundle defined in Section 5 to all Service Providers registered for this entity category, either automatically or subject to user consent or notification, without administrative involvement by any party.
An Identity Provider that supports this entity category would exhibit the following entity attribute in SAML metadata:
<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
<saml:Attribute
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="http://macedir.org/entity-category-support">
<saml:AttributeValue>https://refeds.org/category/pseudonymous</saml:AttributeValue>
</saml:Attribute>
</mdattr:EntityAttributes>