...
Broadly this means that R&S is intended for platforms and services used by researchers or scholars where some sort of collaboration, discussion or other interaction between users is required, making the release of personally identifiable information necessary for the service to work properly. This services may be both paid for or freely available services - the focus of the category is on the nature of the service offering and legitimate requirements for attributes.
Think about issues like:
- Is it necessary for a name to be displayed in order for work to be attributed to the user or to show them as the contributor? (a wiki is a prime example)
- Is it necessary for a service to have a user's email address for correspondence such as updates about a grant application? (optional services such as alerting systems that are not part of the core offering would not be considered a good reason for R&S membership).
...
Service Providers should only request attributes that the service actually uses, so for example if email address is not required by the service it should not be requested. The specification does not explicitly prevent Service Providers from requesting attributes outside the R&S attribute bundle but strongly suggests that they do not ("Service Providers SHOULD request a subset of R&S Category Attributes", section 5 of the specification). R&S works best for both Identity Providers and Service Providers when the bundle is treated as the maximal set of attributes requested. The specification gives the following advice:
Service Providers SHOULD limit their data requirements to the bundle of attributes defined in Section 5, but MAY negotiate for additional data as required via mechanisms that are outside the scope of this specification.
The category specifies "SHOULD" so as to not unintentionally disallow scenarios where there is a very good reason to ask for an extra attribute, although providers are encouraged to stick to the R&S bundle where-ever possible. An example exception might be where a contractual arrangement exists and specific attributes (e.g. eduPersonEntitlement) are used to help flag this contractual arrangement.
...
Service Providers should reference the eduPerson specification for details on values that may be received per attribute, but in general terms:
...
Category support is defined as follows:
An Identity Provider supports indicates support for the R&S Category if for some subset of the Identity Provider's user population, the Identity Provider releases a minimal subset of the R&S attribute bundle to 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, either automatically or subject to user consent or notification, without administrative involvement by any party.
See section 6 Section 7 of the R&S Entity Category specification for a precise definition of the minimal subset of the R&S attribute bundleEntity Category gives details of how IdPs should implement support. Effectively managing use of eduPersonPrincipalName and eduPersonTargetedID in relation to reassignment is one of the areas that causes the most confusion. For the avoidance of doubt, REFEDS recommends that if you support both, release both.
How do I configure an IdP to release attributes to R&S SPs?
...
What Federations are Using R&S?
The following federations have implemented R&S with a subset of their members:
- ACOnet Identity Federation / eduID.at
- CESNET / eduID.cz
- DFN (German only)
- IDEM GARR AAI
- InCommon
- SWAMID
- SWITCHaai
- UK federation
Information is available at: Entity Category Usage.