The formal, approved definition of the REFEDS Research and Scholarship (R&S) Entity Category is published on the REFEDS website:
http://refeds.org/category/research-and-scholarship
(Note that the URI value of the REFEDS entity attribute resolves to the R&S specification.)
The category definition says that:
Candidates for the Research and Scholarship (R&S) Category are Service Providers that are operated for the purpose of supporting research and scholarship interaction, collaboration or management, at least in part.
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.
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. Think about issues like:
As a federation, you should be satisfied that the release of personal data is an essential part of the operation of the service (and not purely to activate added features) and that the service in question, whether commercial or not, exists to support research and scholarship as a primary function.
Services that should not be included in this category include:
Collaboration is a sufficient condition for inclusion in the R&S category. Thus a service that functions as a collaborative tool (at least in part) meets the intent of this category.
A wiki is probably the most obvious example of a collaborative service. Other examples include (but are not limited to): calendaring and scheduling tools, content and document management systems, and mailing list software.
Scientific research (broadly defined) is inherently a collaborative endeavor, and so web apps, portals, and computational tools for researchers clearly satisfy the intent of R&S. Collaborative learning platforms for research or education are also candidates for the R&S category.
An important characteristic of collaborative tools and services is that they require the user’s name to function effectively. Hence, the R&S attribute bundle includes a name-based identifier (eduPersonPrincipalName) and person name as essential attributes. The user’s email address is also included in the bundle, to facilitate communication among the users of the service and between the service and its users.
The Research & Scholarship specification defines a bundles of attributes that Identity Providers are encouraged to release to R&S services:
Category support is defined as follows:
An Identity Provider supports 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 R&S Service Providers without administrative involvement, either automatically or subject to user consent.
See section 6 of the R&S Entity Category specification for a precise definition of the minimal subset of the R&S attribute bundle.
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.
That said, if an SP requests an attribute outside the R&S attribute bundle, an IdP that supports R&S is by no means required to release it. See the previous question for details about attribute release.
To release attributes to all current and future R&S SPs with a one-time configuration, an IdP leverages entity attributes (instead of entity IDs). Thus the configuration steps documented in the R&S IdP Config topic require Shibboleth IdP v2.3.4 or later, which fully supports using entity attributes in SP metadata as part of an attribute release filter policy.
No other SAML IdP software is known to support entity attributes at this time.
The short answer is no. An IdP must release attributes to all R&S SPs before it can assert the REFEDS R&S entity attribute in metadata.
Consider, for example, an IdP that releases the minimal subset of the R&S attribute bundle to any SP that is a member of both the Code of Conduct category and the Research & Scholarship category. That IdP is not eligible to receive the REFEDS R&S entity attribute in its metadata.
As another example, consider an IdP that releases the minimal subset of the R&S attribute bundle to any R&S SP in the InCommon Federation (but no other federation). That IdP may not receive the REFEDS R&S entity attribute in its metadata.
Finally, consider the following counterexample. Suppose an IdP releases the minimal subset of the R&S attribute bundle to any R&S SP provided the user is a non-student. That IdP may indeed receive the REFEDS R&S entity attribute in its metadata since it supports the R&S category "for some subset of the Identity Provider's user population," as required by the REFEDS R&S specification.
The following REFEDS R&S requirement:
4.3.1 The Service Provider is a production SAML deployment that supports SAML V2.0 HTTP-POST binding.
may be interpreted as the following pair of requirements:
The Service Provider supports standard SAML V2.0 Web Browser SSO. In particular, the Service Provider has an endpoint in metadata that supports the SAML V2.0 HTTP-POST binding.
The Service Provider is a production deployment or one of a group of services that together comprise a production deployment.
The latter includes dev and/or staging instances of the overall Service Provider deployment.
Some tips and suggestions for implementing the Research & Scholarship Category are given in a separate document. In particular, a strategy for jump starting the R&S category using a second support category is outlined.
The GÉANT Data Protection Code of Conduct is a process that allows Service Providers to commit to a series of declarations of support for data protection within the context of the EU Data Protection Directive. Like R&S, it results in the application of an entity category tag and is intended to give greater confidence to IdPs when releasing data.