Date

Connection Details

Attendees

Goals

Discussion items

TimeItemWhoNotes
15:00Welcome, backgroundNicoleNicole gave a brief background reminder of the process to date and why we are here.  Leif put on the table the option of not having a generic category but adding very specific factual tags (e.g. ISCED 6). This would limit the issues with scope not meeting each use case but it is more burdensome for FO, IdP and SP to manage.
15:05Which IdP tags should be pursued?  All

 It was agreed the academia and self sign-up would be the most appropriated tags to pursue at this stage and that these could be investigated at the same time.  The only other area that might emerge is for something that indicates an entity representing a virtual organisation or something that is very specifically resesarch / e-infrastructure based.

self-signup: example use case would be having self-signup is an indicator that the SP has to do some kind of step up to authorize. IoLR has some of this; we could start there. Do we want a self-signup IdP with assurance, or are we talking about a user’s ability to self-administer? This becomes complicated - some IdPs are freefall self-signup, but then there are organizations that start with self-signup but then do significant vetting. You wouldn’t trust a claim of “faculty” from ProtectNetwork, but you could trust a claim of “student” from public schools in Sweden.

15:20Review of current Academia textAll

One of the issues raised was on the difference between Academia and InAcademia and that the tag and the service may be confused.  This should be raised as part of the consultation with a view to perhaps using a different name, but it would be difficult to identify an appropriate one. 

Examples of groups that might not meet the current definition were raised on the REFEDS list.  It was felt that this could be well managed with the "catch all" option given in the definition but that these should be fully noted as part of a formal consultation.

It is expected that these tags will be used to help control and managed discovery and that this should be taken into consideration as part of the documentation. 

Concerns were raised about how the tag would be used and that it should not be a simple lazy replacement for authorisation but as a flag to help organisations manage their processes better.   The tag is not intended to replace affiliation but to help decorate and inform that process.  As indicated on the original pages for the Academia discussion, we expect this to be used in combination with other processes.  The overall approach should be seen as equivalent to adding domain knowledge to keys. 

Concern about what the tags will be used for, and what it means for the user experience. Leif points out that this is a problem we have today; if there is disagreement as to whether a tag is correct, you would contact the federation operator. Chris suggests that we’ll see a flurry of tagging and arbitration required by fedops, and that we need to clearer information as to how this should be used so we can handle that arbitration.  

There are concerns about the difference between curated tags and non-curated tags and how we should managed that moving forward. 

The process for how to object if someone does not correctly tag was discussed.  Nicole explained the current process for R&S - this should be more formally established as a complaints process for all REFEDS entity categories. 

15:50Next stepsNicole

It was agreed that the following actions should be taken:

  • Work with FIM4R and AARC to gather more use cases for Academia.
  • Resolve the outstanding issues on github: https://github.com/leifj/academia-category/issues.
  • Start a new consultation on the proposed text for Academia.
  • Start drafting text for self sign-up categor(ies).

Action items