The REFEDS Steering Committee has approved the launch of a consultation on the adoption of the Academic Institution Entity Category (see also: forked repo within REFEDS) by REFEDS. This updates and improves on a previous proposal for an Academia Entity Category.
The Consultation starts on 24th November 2017 and closes on 8th January 2018 (17:00 CET). Participants are invited to review the full text and make change proposals in the table below, via issues on the github repository or by email to the REFEDS Coordinators and to express their support / dissension for the category. It is recommended that you also read the prepared notes on the original proposal and the previous consultation. Discussion is invited at: consultations@lists.refeds.org.
The main changes in the new proposal are:
The proposed text for the category is available at: https://github.com/leifj/academia-category/blob/master/academia-entity-category.md. The notes are available at: Academic-Academia. All comments should be made on: consultations@lists.refeds.org or added to the change log below. Comments posted to other lists will not be included in the consultation review. |
As this category has been contentious in the community, we are asking for organisations to express their support or dissension below to allow us to gauge the appropriateness of REFEDS adopting this approach.
| Name | Organisation | Reason |
|---|---|---|
Change Log for the Consultation on the Academia Entity Category. The Consultation starts on 20th November 2017 and closes on 8th January 2018 (17:00 CET). Please fill in your proposed changes to Academia Category below or add them as issues on the github repository.
Number | Current Text | Proposed Text / Query | Proposer | Action |
|---|---|---|---|---|
| 1 | 5.3.3 The Identity Provider releases the eduPersonScopedAffiliation attribute. | Should this imply to release this attribute *always* to *all SPs*, including to publishers that are happy with only 'common-lib-terms'? Why should just the IdPs need to do something and not the SPs? | Thomas Lenggenhager (SWITCH) | https://github.com/leifj/academia-category/issues/26 Change to make the registration criteria "the Identity Provider commits to releasing appropriate required attributes to Service Providers". Pull request submitted. |
| 2 | http://refeds.org/category/academic-institution | Given that the REFEDS website now does https by default, should this be https://refeds.org/category/academic-institution Comment from Peter Schober: For consistency with existing/published categories I'd stay with http. | Guy Halse (SAFIRE) | https://github.com/leifj/academia-category/issues/27 as MFA is https, no harm in changing. added to github. |
| 3 | 5.3.3 The Identity Provider releases the eduPersonScopedAffiliation attribute. | How should the Identity Provider’s registrar perform this mandatory check? Would a statement by the IdP administrator be sufficient ? | Thomas Lenggenhager (SWITCH) | https://github.com/leifj/academia-category/issues/26 See solution for point 1. Pull request submitted. |
| 4 | 3. The following URI is used as the attribute value for the Entity Category... | Under section 5 only requirements for Identity Providers are defined but normally an IdP uses Entity Support Category not Entity Category. Is this per design or only a mistake? Comment from Rhys Smith: "normally an IdP uses Entity Support Category not Entity Category" - is correct, but only by coincidence. An entity that has a specific categorisation has an entity category. It just so happens that so far, all categorisations have been for SPs, and so the IdPs have the ESC. This is a categorisation about an IdP, so it's right the IdP has an EC. If there was a corresponding ESC, it would be assigned to the SP that supports that IdP EC. Propose dropping ECS text. Comment from Peter Schober: https://refeds.org/category/hide-from-discovery is an(other) existing Entity Category for IDPs. | Pål Axelsson (SWAMID) | https://github.com/leifj/academia-category/issues/28 Remove reference to Entity Category Support. Pull request submitted. |
| 5 | 5.3.3 The Identity Provider releases the eduPersonScopedAffiliation attribute. | I would say that the behaviour of releasing euPersonScopedAffliliation to all SPs is not privacy by design as described in GDPR. It's a step away from data minimisation. euPersonScopedAffliliation is personal data even though it is not unique personal data. | Pål Axelsson (SWAMID) | See TL comment. See solution for point 1. Pull request submitted. |
| 6 | Add to section 5 | 5.4. additional recommendations 5.4.1 It is RECOMMENDED that IdP releases a unique, persistent and not targeted ID to Service Providers that support and display in their metadata the Research and Scholarship Entity Category [R&S] ... 6. References add: [R&S] REFEDS Research and Scholarship Entity Category v1.3 Sept. 2016 see https://refeds.org/category/research-and-scholarship | Peter Geitz (DAASI) | https://github.com/leifj/academia-category/issues/29 Agreed that cross-referencing specs is not a good idea. Principle met to some extent in solution for point 1. |
| 7 | Section 2 | is point 3 - "the institution is a research hospital, library or archive." meant to mean "research hospital, research library, or research archive", or what it says on the tin? | Rhys Smith (Jisc) | https://github.com/leifj/academia-category/issues/30 Clarification accepted - add pull request on issue. Pull request submitted. |
| 8 | 5.3.3 | how does a registrar check if an IdP releases ePSA? | Rhys Smith (Jisc) | See TL comment See solution for point 1. Pull request submitted. |
| 9 | section 5. "Failure to do so MUST result in revocation of the entity’s membership in the category." Who makes the decision to revoke? | "Failure to do so MUST result in the registrar revoking | Mikael Linden (CSC) | Clarification accepted. Added to refeds fork. |
| 10 | Regarding #1, #3 & #8 on 5.3.3 | How about adding "5.3.3 The Identity Provider releases the eduPersonScopedAffiliation attribute, on request." So that the request can include metadata and inline attribute requests. | Brook Schofield | See comments above. Clarification accepted, moved forward with point 1. Pull request submitted. |
| 11 | Academic vs Academia |
| Brook Schofield | https://github.com/leifj/academia-category/issues/32 Clarification accepted. Added to github. |
| 12 | Attribute Authorities | The document only talks about Identity Providers. I guess we should also be concerned about Attribute Authorities (whether "co-located" with an IDP or stand-alone) asserting those same attributes? | Peter S. | Noted but seen as non-solvable with current status. |
| 13 | Add Link | Maybe add URL/link to eduPerson 201602 reference, http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html | https://github.com/leifj/academia-category/issues/34 Clarification accepted. Added to github. | |
| 14 | Reference | The reference [AcademicInstitutionWikipedia] is unused | Review and accept. Added to github. | |
| 15 | Section 4: Specifically a relying party SHOULD NOT assume that an attribute assertion received from an Identity Provider | "than an | https://github.com/leifj/academia-category/issues/33 Review and accept Added to github. |
Editorial/minor comments:
Attendees:
Miro, Thomas, Nicole, Pål, Heather
eduPersonScoped Affiliation - needs a longer conversation
This is not well defined or scoped in the current draft. Just because something has the academic tag, you should still rely on scoped affiliation for individual decisions. Just because the institution is academic, the individual may not be an academic. This section is worded poorly. See Brook’s suggestion. This would fix the GDPR part since it would be “on request” and “as appropriate”. It should also not be under the registration criteria. Perhaps under registration ask for a statement from the IdP that they will do this as appropriate and check for that. Nicole will think of some wording on this.
Https - in principle, yes, but given that every other entity category is http we’ll stick with that for now and consider a change to https for all entity categories at one time in the future. (After call follow up - Pål noted that MFA has already shifted to https so could be implemented here).
Entity support category and entity category - it is correct that the IdP is the entity category, but there is some wording in there to be cleaned up.
Chapter 5 - not on board with mixing the categories together. Would like to avoid cross referencing. (Pål agrees) Miro asks how this would be implemented - what would happen with institutions and in a fully automated world. R&S is aimed at SPs, Academia is about organizations, and putting both in would make people confused. Also, how to deploy doesn’t belong in the specification. Will not support this one.
Section 2 point 3 - clarification request. It should be research library, research hospital, etc.
Revocation - clarification request that the registrar much handle the revocation
Comment 11 - simple fix, we missed one
Section 4 - clarification request should it say attribute assertion or just assertion?
Attribute authority - agree with Peter in principle, we have been moving towards taking Has out of our documentation because they aren’t being used broadly. Trying to define how an AA would work in this context would be hard.
What about eduTEAMS? No concept of how it works; it depends on which configuration of eduTEAMS the are talking about. This is too big and tangential for this category. Leave this off until we have a good use case that describes how an AA can be an academic institution.
Research libraries question (Pål) - not in GitHub - eduIDs as when you put forward a service that creates identity for users at academic institutions (Part 2 of the spec). It is doing things on behalf of academic institutions, but it is not itself an academic institution. OpenAthens is a similar situation, and there is wording to cover this use case in the spec by stating “on behalf of”. This is going to happen more and more, the breakdown between organization, institution, and technical infrastructure.