In July 2014, it was noted that there was an error in the R&S Enttiy Category definition and REFEDS participants agreed to make changes to fix this error and were invited to propose other minor updates. As there is live usage of the R&S Entity Category it was agreed that changes in this review should be kept as minimal as possible so as not to create major changes to the meaning of existing implementations. This should be used as the driving decision point for the review.
Changes request July - August 2014:
| Number | Current Text | Proposed Text | Action |
|---|---|---|---|
| #1 | "A registrar claims that...The Service Provider will not use attributes released for purposes that fall outside of the R&S definition." | “The Service Provider claims that it will not use attributes for purposes that fall outside of the service definition.” | Accept. This is a clear error in the definition. |
| #2 | "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." | "Service Providers SHOULD only request attributes that the service actually uses. Moreover, Service Providers SHOULD NOT request attributes outside of the R&S Category attribute bundle, except with the understanding that additional negotiation on a per-IdP basis will most likely be involved." | Reject, this is not part of the definition but is implementation advice. Move this to advisory FAQ / implementation guide. |
| #3 | "Candidates for the Research and Scholarship (R&S) Category are Service Providers that support research and scholarship interaction, collaboration or management as an essential component.” | "Candidates for the Research and Scholarship (R&S) Category are Service Providers that support research and scholarship interaction, collaboration or management as their primary activity.” | Reject, not enough consensus. Make better use of the advisory FAQ / implementation guides to address concerns over eligibility. |
| #4 | "Identity Providers are strongly encouraged to release the following bundle of attributes to R&S category Service Providers: * personal identifiers: email address, person name, eduPersonPrincipalName. * pseudonymous identifier: eduPersonTargetedID. * affiliation: eduPersonScopedAffiliation. Where email address refers to the mail attribute and person name refers to displayName and optionally givenName and sn (i.e., surName). An Identity Provider supports the R&S Category if, for some subset of the Identity Provider's user population, the Identity Provider releases a minimal subset of the R&S attribute bundle to R&S Service Providers without administrative involvement, either automatically or subject to user consent. The following attributes constitute a minimal subset of the R&S attribute bundle: * eduPersonPrincipalName * displayName OR (givenName AND sn) For the purposes of access control, a non-reassigned persistent identifier is required. If your deployment of eduPersonPrincipalName is non-reassigned, it will suffice. Otherwise you MUST release eduPersonTargetedID (which is non-reassigned by definition) in addition to eduPersonPrincipalName. In any case, release of both identifiers is RECOMMENDED.” | “Identity Providers are strongly encouraged to release the following bundle of attributes to R&S category Service Providers: * personal identifiers: email address, person name, eduPersonPrincipalName. * pseudonymous identifier: eduPersonTargetedID. * affiliation: eduPersonScopedAffiliation. Where email address refers to the mail attribute and person name refers to displayName, givenName and sn (i.e., surname). An Identity Provider supports the R&S Category if, for some subset of the Identity Provider's user population, the Identity Provider releases a minimal subset of the R&S attribute bundle to R&S Service Providers without administrative involvement, either automatically or subject to user consent. The following attributes constitute a minimal subset of the R&S attribute bundle: * eduPersonPrincipalName * displayName OR (givenName AND sn) For the purposes of access control, a non-reassigned persistent identifier is REQUIRED. If your deployment of eduPersonPrincipalName is non-reassigned, it will suffice. Otherwise you MUST release eduPersonTargetedID (which is non-reassigned by definition) in addition to eduPersonPrincipalName. In any case, release of both identifiers is RECOMMENDED. If a Service Provider lists '''any''' of the person name attributes in metadata, the Identity Provider MUST release some form of person name, either displayName or givenName + sn. Beyond that, an Identity Provider is NOT REQUIRED to release any attribute not listed in metadata.” | Reject. Tying R&S to requested attributes given the known problems with that approach would not be wise. (accept minor typo amendments suggested by I2). |
| #5 | "Candidates for the Research and Scholarship (R&S) Category are Service Providers that support research and scholarship interaction, collaboration or management as an essential component.” | "Candidates for the Research and Scholarship (R&S) Category are Service Providers that are operated for the purpose of supporting research and scholarship interaction, collaboration or management, at least in part." | Accept |
Change log for consultation on the Research and Scholarship Entity Category:
Questions for further discussion on the REFEDS list:
| Number | Requested Action | Response |
|---|---|---|
| 1 | Remove requirement for administrative contact | Implemented |
| 2 | Change the name 'provenance' to 'registration criteria' | Implemented |
| 3 | Use RFC2119 references | Implemented |
| 4 | Change wording on metadata refresh and verification to "Service Provider *claims to*" and remove reference to verification | Implemented |
| 5 | Don't use url-encoded characters for the url | Final version will be moved to the REFEDS wiki and resolve at the URL for the entity category so this won't be an issue |
| 6 | Tidy up Identity Provider / Service Provider / IdP / SP consistency | Implemented |
| 7 | Remove requirement for technical contact | Not implemented |
| 8 | Add requirement for mdui:InformationURL | Implemented |
| 9 | Internet2 proposal for a section on 'deployment considerations': | This has not been implemented. Most of the recommendations are good practice guidelines for doing federated access and are NOT specific to the R&S Entity Category so should be addressed elsewhere. A new section on 'attribute request' has been added to address the issues raised in this section about SP behaviour. |
| 10 | Internet2 proposal for a section on 'normative statements': | This section is only required if the the REFEDS proposal seeks to control the behaviour of ALL R&S like entity categories AND propose its own implementation of it. I would suggest that we ONLY want to seek to control the REFEDS R&S Entity Category, so this section is not needed. For discussion. |
| 11 | Use numbering for ease of reference | Implemented |
| 12 | How do we seek to control currency and appropriateness of R&S tags? | For discussion. Require FO to undertake a lightweight annual review? |
| 13 | Does 4.3.1 need revising? Clumsy at the moment, is binding reference necessary? What does support mean? | For discussion |
| 14 | Change the definition section to: Traditionally, the three dimensions of academic endeavor are: research and scholarship, instruction, and service. A candidate for the Research & Scholarship Category is a Service Provider that supports research and scholarship as an essential component. | Not implemented. |