...
- Maybe add URL/link to BCP 14 reference, https://www.rfc-editor.org/info/bcp14
- Maybe add URL/link to eduPerson 201602 reference, http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html
- The reference [AcademicInstitutionWikipedia] is unused
- At the end of section 5 there's an instance of "Academia Identity Providers" left.
- "than an
attributeassertion received" – i.e., remove "attribute ", "assertion" alone suffices.
Notes from Call: 14/03/2018
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.