This document is an attempt to clarify the R&S specification to address issues that have arisen in its initial deployment by federations, particularly confusion over its relationship to other, unrelated mechanisms and regimes for attribute release faciliationfacilitation. It also attempts to clarify what an SP and IdP are obligated or assumed to be doing, and moves some "implicit" guidance into formally suggested behavior.
...
Example Service Providers may include (but are not limited to) collaborative tools and services such as wikis, blogs, project and grant management tools that require some personal information about users to work effectively. This Entity Category should not be used for access to licensed content such as e-journals.
Identity Providers may indicate support for Service Providers in this category (typically through self-assertion, though this is not required) to facilitate discovery and improve the user experience at Service Providers.
The following sections detail the requirements for both Service Providers and Identity Providers, in category membership and support respectively.
2. Syntax
The following URI is used as the attribute value for the Entity Category and Entity Category Support attribute:
http://refeds.org/category/research-and-scholarshipRefer to Section 8 for usage examples.
3. Semantics
By asserting a Service Provider to be a member of an Entity Category, a registrar claims that:
...
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 typically required for effective use of R&S services. The attributes chosen represent a privacy baseline such that further minimization achieves no particular benefit to a user. Thus, the minimal disclosure principle is already designed into the category.
...
All of the above attributes are defined by or referenced in the [eduPerson] specification. The specific naming and format of these attributes are is guided by the protocol in use. In the case of SAML 2.0 the [SAMLAttr] profile MUST be used. This specification may be extended to reference other protocol-specific formulations as circumstamces circumstances warrant.
6. Service Provider
...
Requirements
Service Providers SHOULD request a subset of R&S Category Attributes that represent only those attributes that the Service Provider requires to operate its service.
...
Service Providers are strongly encouraged to support all of the alternative formulations specified alternatives for the shared user identifier and person name attributes described in Section 5 to maximize interoperability. Failure to do so will result in problems even when working exclusively with Identity Providers that claim support for the category. In the case of the eduPersonTargetedID attribute, this recommendation includes the ability to support SAML 2.
TBD: A note here related to the reassignment issue? I don't have specific text in mind, but this seems like a place a brief discussion on it could go.
...
0's "persistent" Name Identifier format, which is the recommended modern expression of the eduPersonTargetedID attribute in SAML 2.0.
In accordance with the requirements in Section 7, if an Identity Provider exhibits the R&S entity attribute in its metadata and no accompanying eduPersonTargetedID attribute is recieved, then Service Providers can rely on the non-reassignment of eduPersonPrincipalName values it receives from that Identity Provider.
Alternatively, Service Providers can obtain a non-reassigned shared user identifier by combining (e.g., concatenating) the eduPersonPrincipalName and eduPersonTargetedID values. If a given combination of the two values ever changes, Service Providers can assume that the eduPersonPrincipalName has been reassigned and now represents a different subject.
A Service Provider that conforms to R&S would exhibit the following entity attribute in SAML metadata:
| Code Block | ||
|---|---|---|
| ||
<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>http://refeds.org/category/research-and-scholarship</saml:AttributeValue>
</saml:Attribute>
</mdattr:EntityAttributes> |
7. Identity Provider Requirements
An Identity Provider indicates support for the R&S Category by exhibiting the R&S 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 R&S Service Providers without administrative involvement by any party, either automatically or subject to user consent.
An Identity Provider that does not release all of the required elements of the R&S attribute bundle (shared user identifier, person name, email address), for any reason, SHALL NOT exhibit the R&S entity attribute in its metadata. Exceptions, limiting the release of attributes to specific R&S Service Providers, may be permitted in the event of a security incident or other isolated circumstances.
For the purposes of effective access control, A persistent, non-reassigned, non-targeted identifier is REQUIRED. If the Identity Provider’s deployment of eduPersonPrincipalName is non-reassigned, and the organization believes in good faith that it will remain so, it will suffice. Otherwise the Identity Provider MUST release eduPersonTargetedID (which is non-reassigned by definition) in addition to eduPersonPrincipalName. In any case, release of both identifiers is RECOMMENDED. Likewise the release of all three person name attributes (displayName, givenName, sn) is also RECOMMENDED.
An Identity Provider that does not support all of the required elements of the R&S attribute bundle, for any reason, SHALL NOT claim support for this category; that is, the Identity Provider SHALL NOT exhibit the R&S entity attribute in its metadata. Exceptions, limiting the release of attributes to specific R&S Service Providers , may be permitted in the event of a security incident or other isolated circumstances.
Identity Providers are strongly encouraged to release the entire attribute bundle (both required and optional attributes) defined in Section 5 to R&S category Service Providers, both to maximize interoperability and the scope of supported services. The only optional data element is affiliation, which while different in nature to the rest of the bundle, is important to many R&S services and is a particular differentiator for academic organizations.
8. Examples
A Service Provider that conforms to R&S would exhibit the following EntityAttribute in SAML metadata:
...
| title | An entity attribute for SPs that conform to R&S |
|---|
...
.
...
An Identity Provider that supports R&S would exhibit the following EntityAttribute entity attribute in SAML metadata:
| Code Block | ||
|---|---|---|
| ||
<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"> <!-- entity attribute for IdPs that support R&S --> <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"> <!-- the refeds.org R&S entity attribute value --> <saml:AttributeValue> httpAttributeValue>http://refeds.org/category/research-and-scholarship <scholarship</saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> |
...