Research & Scholarship Category FAQ for Identity Providers
Which services are eligible for the Research & Scholarship category?
Candidates for the R&S category include InCommon service providers that support research and scholarship as an essential component. For example, a service providing tools for both multi-institutional research collaboration and instruction is eligible as a candidate for the R&S category. (A service intended to support instruction alone is not eligible, however.)
InCommon reviews all applications from potential R&S service providers. The InCommon Technical Advisory Committee and the InCommon Steering Committee review and approve the requests. Visit the Federation Info pages for a complete list of all R&S service providers.
Which attributes are released as part of the Research & Scholarship category?
The R&S category defines the following attribute bundle:
- personal identifiers: e-mail address, person name,
eduPersonPrincipalName - pseudonymous identifier:
eduPersonTargetedID - affiliation:
eduPersonScopedAffiliation
where e-mail address refers to the mail attribute and person name refers to displayName and optionally givenName and surName.
InCommon identity providers that support R&S release some subset of this attribute bundle to R&S category SPs. Sites are strongly encouraged to configure their IdPs to support R&S.
Do all R&S SPs require all attributes in the bundle?
InCommon highly recommends that SPs take a minimalist approach to attributes, only requesting those attributes that they absolutely need. IdPs are encouraged to implement a default policy that releases the R&S attributes to SPs in the R&S category. This requires a one-time change to the IdP's deployment configuration. More detailed deployment guidance will be found elsewhere in this wiki. As a side note, a number of IdPs intend to release these attributes to all SPs by default.
Do I need to configure my IdP to release attributes to each and every R&S SP?
No. A one-time configuration is all that's needed. Let me try to explain.
Today most IdPs configure their attribute release policies around the SP's entity ID (i.e., on an SP-by-SP basis). Every time you type an entity ID into your IdP software configuration, you paint yourself into an ever-smaller corner. To better scale the Federation, we recommend that IdPs configure their attribute release policies using entity attributes instead of entity IDs. This leads to a more robust deployment that is much easier to maintain.
What is an entity attribute?
Once an SP becomes an R&S SP, it receives the R&S entity attribute in metadata. You can support a single R&S SP by configuring its entity ID into your IdP software configuration, or you can support all R&S SPs by configuring the corresponding entity attribute. The latter scales better since it is a one-time configuration change.
What are the deployment options at the IdP?
An IdP has at least three options (in increasing order of deployment difficulty):
- Release a fixed subset of the R&S bundle (or the R&S bundle itself) for all SPs
- Release a fixed subset of the R&S bundle (or the R&S bundle itself) for all R&S SPs
- Release a precise subset of the R&S bundle for each R&S SP (on an SP-by-SP basis)
The Shibboleth IdP software supports either of the first two options out-of-the-box. The latter option requires a special plugin at the Shibboleth IdP. Deployment options are discussed more thoroughly in the wiki.
Does the release of these attributes violate FERPA or other compliance requirements?
We do not believe so. We have worked with university counsels, registrars, and associate provosts to review these issues but have found none to date. We have summarized the relevant policy issues in the wiki. We encourage campuses to reach out and talk to someone that has implemented R&S for further information.
Where can I find complete information on the Research & Scholarship Category?
There is detailed information on the Research and Scholarship Category elsewhere in this wiki.