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.
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.