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:
...
Service Providers are strongly encouraged to support all of the 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.
...
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:
...