...
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:
- 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).
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:
...
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. Service Providers requiring more unique / bespoke attribute bundles should talk to the discuss their use case with the wider REFEDS community.
What exactly is meant by a "production SAML deployment?"
...