Introduction
Several different use-cases have been put forward describing requirements to identify individuals who fit some sort of description of academic and / or Identity Providers that are from academia. Due to significant global and local differences in the way that these concepts are implemented and used it is not possible to come up with a single easy-to-use solution for these requirements. There are approaches that can be taken. REFEDS and it members are attempting to a) document possible misunderstandings regarding existing federation metadata and b) document possible pragmatic solutions that may meet the requirements put forward by user groups.
Definitions
There are many different definitions of both academic and academia used globally. For the sake of this work, the following two definitions will be used:
- ISCED: International Standard Classification of Education
- Wikipedia definition of Academic Institution
Known Issues
| Existing Issue | Discussion |
|---|---|
| Research and Education federations have IdPs that do not belong to "educational" bodies. | Whilst most federations place some restrictions around IdPs and limit the registration of them to sub-sets of user groups it is not possible to fully limit IdPs to organisations that are strictly academic. |
| There is no wide-spread use of the term "faculty". | Faculty is used in the eduPerson specification and is the closest value to "academic" that currently exists, however it is not widely used as a term outside of the US. For more background on the usage of affiliation see the REFEDS ePSA usage comparison. |
| "Faculty" and "Academic" are different things | Faculty specifically refers to the academic staff of an organisation in the US. Academic could include students, academic-related staff (librarians, IT, researchers) etc. |
| IdPs do not typically group or label individuals as academic in systems. | Use of academic / academic-related is normally restricted to pay-grade systems and is not a generic tag that would typically be assigned to user groups. |
| Academia IdPs may serve various user groups | Many guests (like consultants, participants in part-time further education courses, etc.) that get an account in an academia IdP will generally not qualify as academic users. These guests would typically get an affiliation value of 'affiliate' or no value at all. |
| Non-academia IdPs are not tagged. | There is currently no flag for "non-academic" IdPs. Such a tag could be explored but it would probably be considered negative by the entity owners. It would also be subject to misinterpretation and misuse - if Google is used by 3 academic users as an IdP, is it therefore academic? Also there is no authorative source for labeling the non-members. |
| Confusing terms-of-use and authorisation. | There are scenarios where a terms-of-use style agreement with the user (e.g. you can only use this in x scenario, you can only download one copy) has been translated into an authorisation requirement (you must be a person of type x). These translations can often lead to bad-fit and confusion. |
| Hub and Spoke federations have challenges supporting entity categories | Many hub and spoke federations are providing virtualisation to allow features to be added that support interactions such as entity tagging. |
| Academics might not be in "academia" IdPs | Many academics will be using specific VO IdPs rather than the IdP of a recognisable "academic" organisation. Should it be permissible for these to be tagged with "academia" |
Use Cases
- InAcademia
The InAcademia service wishes to be able to easily limit usage of its service to those IdPs that can authoritatively issue user affiliation with an academic institution. - CLARIN
CLARIN has a series of licenses, one of which restricts use of materials to academic uses (ACA: "for educational, teaching or research purposes") and desires this to be managed via authentication / authorisation. - ELIXIR
Any natural person is eligible to have an ELIXIR identity. On the other hand, use case analysis has demonstrated a need for certain “ELIXIR community membership” or “bona fide life science researcher” status which would qualify the user to some basic services. ELIXIR have written up a requirements paper on their AAI needs.
Proposed Solutions
There is no one-size fits all solution to the needs of the community. REFEDS could propose the creation of a toolbox with three parallel and complementing tools. Defining values alone will not move the requirements forward as Service Providers will still be faced with the problem of ensuring that attribute release is occurring. Entity Category work could support this need.
1. for IdP entities in SAML2 metadata | 2. Supporting use of "academia" value with schacHomeOrganisation | 3. Supporting use of eduPerson(Scoped)Affiliation = faculty |
|---|
- Both Solution 1 and 2 need a definition of what "Academia" means.
- Solution 3 likely needs to include at least "Student"