Page History

...

The InCommon R&S Category vs. the REFEDS R&S 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. The REFEDS R&S specification was revised to V1.2 on November 28, 2014.

<hr>

Privacy

[Item 1] Here is the relevant phrase from the Participation Agreement:

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.

Compare the above passage with the following quote from the REFEDS R&S Category specification:

Service Provider claims that it will not use attributes for purposes that fall outside of the service definition.

The primary distinction is that the former is included in a signed legal agreement while the latter is self-asserted by the service owner. See, for example, the R&S application form used by InCommon.

Commercial Services

[Item 2] While the InCommon R&S Category keeps the door open to commercial services, the REFEDS R&S Category seems to explicitly rule them out.

Human Subjects Research

[Item 3] Prior to October 27, 2014, the InCommon R&S has Category had 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.

Privacy

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

Requested Attributes

Following the recommendations of both the Technical Advisory Committee and the Steering Committee, this requirement was removed from the InCommon R&S Category on October 27, 2014.

User Interface Elements

[Item 4] All but one InCommon R&S SP already has an mdui:InformationURL in metadata so this particular difference between the two specifications is irrelevant.

Contacts in Metadata

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

Requested Attributes

[Item 6] The REFEDs R&S specification has two requirements regarding requested attributes in metdataIt’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:

...

For clarity, these two requirements are broken into three parts on the R&S application form:

1. [True/False] My service provides requested attributes in metadata.
2. [Yes/No] Are the requested attributes in metadata a subset of the R&S attribute bundle? (Note: This is highly RECOMMENDED otherwise a bilateral agreement with each IdP may be required.)
3. [True/False] My service requests only those attributes required to operate the service.

In particular, the latter is a strict requirement for all InCommon R&S SPs, which goes beyond the REFEDS R&S requirements.

Entity Attributes

Obviously, the entity attribute value for InCommon R&S is different than the entity attribute value for REFEDS R&S. In the short term, the goal is for all InCommon R&S SPs to have a multivalued entity attribute in metadata, that is, each SP will satisfy the requirements of both InCommon R&S and REFEDS R&S (which is possible since the gap between them is small). Once all R&S SPs have a multivalued entity attribute in metadata, all InCommon R&S IdPs will be encouraged to migrate their configurations to the REFEDS R&S entity attribute, that is, to release the R&S attribute bundle to all R&S SPs, globally.

References

• The REFEDS R&S entity category
• The REFEDS R&S FAQ