Jump to: 

What is the Research and Scholarship Entity Category, and why should I care?

Research & Scholarship→ (R&S) is a global program and standard devised to let scholars and researchers quickly and seamlessly access a wiki or collaborative research tool at another university or major research facilities like CERN in Switzerland or the research portal at the National Insitute of Health (NIH) without having to negotiate the often complicated personal data release procedures on campus. We all value user privacy and regard its protection as a high priority. At a basic level, when a user signs in to a resource via federation, a university participating in InCommon might send no personal information beyond the minimum necessary to tells the resource: “this person is a legitimate member of our organization, so please let them in.”

Alas, for a research collaboration to validate a user’s identity in order to grant access to controlled resources, it often needs to know who the signed-in person is and how to contact that person. That’s where R&S comes into play. Think of R&S as an optional add-on to the InCommon infrastructure. When a campus supports R&S, it agrees to send a few more bits of information: a person’s name, email address, and affiliation (e.g. “faculty,” “student,” and the like) to qualifying research resources. InCommon and sister federations around the world control which services are added to the pool of qualifying R&S services. You can be sure that only legitimate research and scholarship providers receive this additional information. 

When your support R&S, when your researcher signs in to a service offered by, say, NIH, NIH knows who the person is and whether to provide access. Back on campus, this gets IT out of the business of having to make a person-by-person decision on whether to send this additional identifying information. 

How does it work?

As noted above, many research services require a few additional pieces of information to connect a user’s campus credential with access to the research resources they need. Let’s take a look at XSEDE: when a user signs into XSEDE via federation for the first time, it uses the personal information sent by the campus to establish a user profile. It optionally compares that information with any internal access roster it may already have, connecting the profile with that roster and grants the signed-in user the appropriate access. On subsequent sign-in, XSEDE may rely on the user information sent by the campus to keep user contact information current and if appropriate, de-provision access.

This capability is critical to some services’ ability to scale support for highly collaborative research projects. Because of it, some research services will only allow login if your campus supports R&S.

A qualified R&S service is validated and tagged by its registering federation (e.g., InCommon) with an R&S tag. When your campus supports R&S, you are agreeing to configure your federated single sign-on service to automatically release the relevant user information (for any individual that may reasonably participate in research collaboration on your campus) to a service tagged with R&S. In addition, you’d declare your support for R&S by asking your InCommon site administrator to add the “Supports R&S” tag to your campus information in the InCommon Federation. 

Resources 

Here are links to the R&S Entity Category specification and an FAQ.

Check to see if your IdP or SP is listed as already meeting the Research & Scholarship specification. 

This wiki page describes how to enable an identity provider (typically a campus single sign-on system) to automatically provide the R&S information to R&S tagged services. Your InCommon site administrator can add the R&S tag to your campus information at the InCommon Federation. Services that qualify can fill out this application to be given the R&S tag.



Working with user data

Related content


Get help

Can't find what you are looking for?