...
Requirements: LoA management
An AAI infrastructure that manages different Level of Assurance (LoA), allow users to use credentials with from sources that provide different level of assurance, and communicate properly the information about the assurance to the service providers.
With this information service providers, but also the user communities themselves, can decide which tasks the user can perform and which services can be accessed by users with the credentials used.
Requiring that all the user credentials have the same LoA regardless of the actions that are performed adds unnecessary overhead, and can discourage new users.
One example of this is that to upload big amount of data, and to use resources, users should be strongly authenticated, while to read open data the lower LoA is enough.
BioVel
At the moment the community has no clear use cases for a differentiated level of assurance, but there are two potential uses for it: enable limited access to citizen science services, with social accounts, and restrict access to other services only for very high assurance credentials.
These use cases have not been formalized yet within the community, but it is a key issue how institutionally affiliated users can be made able to authenticate using a non-institutional mechanism (i.e., FB, Google, etc.) in the same way that some users opt to use a non-institutional email address.
DARIAH
DARIAH services are used for research and educational purposes only.
Therefore users are classified as : belonging to some research institution (access via eduGAIN qualifies for this, or an institutional e-mail address), or so-called citizen researchers.
Accounts that fall into the latter category are checked manually, i.e. mail communication to make sure that user is involved in research. Any institution that is not yet known (mail domains are stored) is checked manually as well, in order to be sorted into one of the two categories.
After this manual check there is no need for further information about differentiated LoA.
PSNC
No need for LOA management is needed for the moment, but there are potential use cases for this that are foreseen for the future.
Photon and Neutron
LoA management is relevant for the Umbrella use case.
CLARIN
For CLARIN LoA management is relevant Yes, LoA is highly relevant: We would like to be able to trace users back to real persons and also have reliable user data to determine the user’s status (for example if they are students or staff).
EGI
EGI supports a very diverse set of use cases. Open data is a typical use case where a very large community of users can access a data set, but there is need for a lightweight authentication to account – for example – the number of connections to a service. In this example EGI needs to enable users without the need for ‘expensive’ high assurance credentials.
Clearly service providers must be able to extract information about the LoA from the attributes associated to the user identity. LoA definitions should be standard and simple, not to over-complicate the service provider decision to allow, or not allow, the user task.
EUDAT
The level of assurance assigned to the user credential is a very important attribute for the EUDAT use cases. EUDAT plans to be as open as possible in terms of the types of credentials accepted, and good practices in the management of LoA would be beneficial for the future development of B2ACCESS.
FIM
Service provider will ultimately decide on supporting low level of assurance identities, what SPs need is to get the information about the LoA in a reliable and standard way.
Requirements: Attribute management and community managed authorization