h2. Research and Scholarship Category

InCommon is offering an easier method for participants to provide collaborative services for researchers and scholars via their federated identities by reducing the policy interpretation, inter-institutional agreements, and system configuration needed for those services. This method categorizes service providers (SPs) to simplify the configuration of identity providers (IdPs); the result is that researchers can successfully access SP sites without delay and without contacting their local IdP admin. The Research & Scholarship (R&S) category applies to service providers that support research and scholarly activities such as virtual organizations and campus-based collaboration services. Participating IdPs agree to release a minimal set of attributes to the R&S category with a one-time addition to their default release policies, a simpler and more scalable approach than negotiating such release bilaterally with every service provider.

{toc:minLevel=3}

h3. Background

A  growing number of Service Providers (SPs) supporting collaborative research and scholarship activities are joining InCommon. As is the standard practice in the higher education and research world, collaboration  on these sites involves knowing who the collaborators are: name, email, institutional affiliation. Unfortunately, the default Attribute Release Policies in place at most campus Identity Providers (IdPs) do not share any information with these sites without local review of the SP's purpose, governing policy, and operational practices. This approach is simply not scalable to the thousands of campus IdPs and thousands of SPs supporting research and scholarship that we anticipate in the future. It is already a serious problem for the big virtual organizations and research labs; the hoped-for explosion of smaller collaboration sites housed in academic departments will not succeed with federation without a scalable solution.

All InCommon SPs are already bound by a set of practices governing how they manage and use personal attributes. InCommon's R&S Category defines additional set criteria that are designed to facilitate IdP policy decisions to release a controlled set of low-risk attributes to R&S SPs without local review for each SP.  InCommon also provides metadata and technology tools to further facilitate automatic, but controlled, release of attributes to the R&S SPs, as well as aiding user support.

IdPs can simplify the management of their Attribute Release Policies by taking advantage of the R&S Category. With a one-time addition to their default release policies they can specify a set of attributes to release to all SPs that are in the R&S Category. This policy would apply to SPs that are added to the category in the future, without the IDP administrator having to make any changes.

{div:style=width:25%;float:right}{info}Browse a list of [all current R&S SPs|https://incommon.org/federation/info/all-sp-categories.html]{info}{div}

h3. Candidate Services

Whether an SP operator is commercial or non-commercial is not relevant to eligibility for the R&S Category, nor are any other aspects of how the service is implemented or operated,  beyond the specific requirements noted below. It's all about purpose.

{info:title=Category Definition}
The three traditional dimensions of the academic endeavor are: research and scholarship, instruction, and service. Candidates for the R&S Category are 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. However, because of the risk involved, a Service Provider that engages subjects in experiments that require specific oversight is not eligible for the R&S Category.
{info}

InCommon has chosen to introduce service categories in a conservative way, by focusing narrowly on services purposed for research and scholarship, in order to make implementation as straightforward as possible, and limit the range of concerns to be as specific as possible. Other service categories may be defined in the future for other purposes.

h3. Requirements for R&S Service Providers

R&S Service Providers must comply with the following requirements:

* The service enhances the research and scholarship activities of some subset of the InCommon community.
* The service meets the following technical requirements:
** Service metadata has been submitted to InCommon and [published in a human-readable format|https://incommon.org/federation/info/all-entities.html] on the InCommon public web site.
** The SP is a production SAML deployment that supports SAML V2.0 Web Browser SSO.
** The SP [refreshes and verifies metadata|Metadata Consumption] at least daily.
** The SP provides an {{mdui:DisplayName}} in metadata (one of numerous [User Interface Elements|User Interface Elements]).
** The SP supports the SAML V2.0 HTTP-POST binding (one of numerous SAML V2.0 [endpoints in metadata|SP Endpoints])
** The SP provides Technical and Administrative [contacts in metadata|Contacts in Metadata].
** The SP provides [requested attributes|Requested Attributes] in metadata.

R&S Service Providers must resolve issues of non-compliance within a reasonable period of time from when they become aware of the issue.  Failure to do so may result in revocation of their membership in the R&S category.

{anchor:Attribute_Bundle}

h3. R&S Category Attributes

InCommon IdPs are strongly encouraged to release the following attributes to R&S category SPs:

* _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}}.

R&S category SPs may request other attributes, but IdP operators will likely require a prior agreement before releasing additional attributes.

With respect to attributes, note that InCommon Service Providers are already bound by the requirements of the [InCommon Federation Participation Agreement|http://www.incommonfederation.org/docs/policies/participationagreement.pdf]. For the purposes of R&S, participants should pay particular attention to Section 9 of that document:

{info}9. Respect for Privacy of Identity Information

Participant agrees to respect the privacy of and any other constraints placed on identity information that it might receive from other InCommon Participants as agreed upon between Participant and the InCommon Participant(s). In particular, Participant understands that it may not permanently store nor share or disclose or use for any purpose other than its intended purpose any identity information that it receives from another InCommon Participant without express written permission of the other InCommon Participant. Participant understands that the storing and sharing of resources is between the Participant and the InCommon Participant(s) and is not the responsibility of InCommon.{info}

It is therefore highly recommended that SPs use a minimalist approach to attributes, only requesting those attributes that they absolutely need. In the future, as InCommon interoperates with federations in other parts of the world, it is likely that IdPs in other countries may be operating under laws and regulations that require a minimalist approach to attribute release.

h3. Application for Inclusion in the R&S Category

To request membership in the R&S Category, a site administrator  for the organization owning the SP [completes a web form|http://www.incommon.org/federation/categories/resschol/] asserting compliance with the criteria.

This initiates the following approval process:

# InCommon staff review the requests, interacting with the submitter and the InCommon Technical Advisory Committee (TAC), as needed.
# Assuming a positive review, the staff provide a one-paragraph summary recommending approval of the request to the InCommon Steering Committee and the TAC, asking for comments within one week.
# Approval or rejection of the request is determined by consensus by the review participants.

When an SP is approved for the R&S category:

# An [entity attribute|InCCollaborate:Metadata Support for the R and S Category] is inserted into metadata.
# The new R&S SP is added to a web page listing [members of the R&S category|https://incommon.org/federation/info/all-sp-categories.html].
# An announcement is sent to the announce@incommon.org email list and/or the monthly newsletter.

{info:title=Policy and Deployment Considerations}
Prospective R&S SPs and IdPs intending to support R&S should consider the [policy|InCCollaborate:Policy Considerations for R and S] and [deployment|InCCollaborate:Deployment Considerations for R and S] implications of R&S.
{info}