Child pages
  • REFEDs Research and Scholarship Gap Analysis
Skip to end of metadata
Go to start of metadata

Gap Analysis of the REFEDs Research and Scholarship Category

This document attempts to identify the differences between the InCommon Research and Scholarship Category and the REFEDS Research and Scholarship Entity Category. The latter was formally adopted by the REFEDS community in February 2014.

 

InCommon R&S Requirement

REFEDs R&S Requirement

1

[Participation Agreement, section 9] 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.

"A registrar claims that...The Service Provider will not use attributes released for purposes that fall outside of the R&S definition."

2

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

"This Entity Category should not be used for access to licensed content such as e-journals."

3

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

 

4

"The SP provides an mdui:DisplayName in metadata..."

"The Service Provider provides an mdui:DisplayName and mdui:InformationURL in metadata."

5

"The SP provides Technical and Administrative contacts in metadata."

"The Service Provider provides one or more technical contacts in metadata."

6

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


"It is therefore highly recommended that SPs use a minimalist approach to attributes, only requesting those attributes that they absolutely need."

"Service Providers SHOULD request a subset of R&S Category Attributes that represent only those attributes that the Service Provider requires to operate its service."

Privacy

[Item 1] The following privacy-related REFEDs requirement is problematic:

A registrar claims that…The Service Provider will not use attributes released for purposes that fall outside of the R&S definition.

REFEDs is currently considering the following reformulation of the above requirement:

  1. Remove section 3.2.
  2. Add section 4.3.6: "The Service Provider claims that it will not use attributes for purposes that fall outside of the service definition."

Human Subjects Research

[Item 3] InCommon R&S has the following additional requirement:

a Service Provider that engages subjects in experiments that require specific oversight is not eligible for the R&S Category.

This refers to research that would require Institutional Review Board (IRB) approval. Note that both TAC and Steering previously agreed to remove this requirement, but final action was never taken. Given the consensus among TAC and Steering members to remove the IRB-related statement, the migration to REFEDs R&S provides an opportunity to finalize that action.

User Interface Elements

[Item 4] All but one InCommon R&S SP already has an mdui:InformationURL in metadata.

Contacts in Metadata

[Item 5] InCommon already requires both technical and administrative contacts in metadata, for all SPs and IdPs.

Requested Attributes

[Item 6] It’s difficult (if not impossible) to reconcile these two REFEDs R&S requirements:

The Service Provider provides requested attributes in metadata.

Service Providers SHOULD request a subset of R&S Category Attributes that represent only those attributes that the Service Provider requires to operate its service.

The latter requirement implies the use of the isRequired XML attribute in SP metadata but InCommon intentionally does not support this XML attribute.

REFEDs is currently considering the following reformulation of the above requirement:

  1. Replace the second sentence above with: "Service Providers SHOULD request a subset of the R&S Category attribute bundle."

References

  • No labels