EGI-Engage:TASK JRA1.1 Proposal for Levels of Assurance
|EGI-Engage project:||Main page||WP1(NA1)||WP3(JRA1)||WP5(SA1)||PMB||Deliverables and Milestones||Quality Plan||Risk Plan||Data Plan|
|WP2(NA2)||WP4(JRA2)||WP6(SA2)||AMB||Software and services||Metrics||Project Office||Procedures|
This wiki pages is a work in progress and it contains a draft proposal for the categorization of the levels of assurance in the scope of the EGI CheckIn service. The CheckIn service aggregates authentication and authorization information from different sources, which have different levels of assurance and may release only a subset of the required attributes. The combined information from the aggregated sources of authentication information results in an overall LoA that is embedded in the assertion sent to the services provider in the EGI Federation.
Level of Assurance
This section contains the proposed categories of level of assurance as interpreted and published by the EGI AAI Proxy (CheckIn service).
This category groups the credentials with basically no LoA associated. Examples are social-identity credentials with no vetting and no uniqueness of the ID guaranteed.
This LoA does not allow to access most of the EGI services, but could be used to access read-only open datasets and track in a qualitative way the number of accesses to a dataset. No sensitive activities can be accessed with this basic credential.
This category groups the credentials that have the minimum features to access
This category groups the credentials that have a level of assurance that is considered aligned with all the EGI policies and allows to access all EGI services. The requirements are the following:
- The accounts in the Home Organisations must each belong to a known individual person
- Accounts must not be shared and the Home Organisation must be able to trace each account back to its holder
- Persistent user identifiers (i.e., no reassignment of user identifiers)
- Documented identity vetting procedures
- The Home Organisations must have a documented identity vetting process for its user accounts. The documentation must be available in English and follow a widely established structure.
- Password authentication
- Or higher security authentication mechanisms
- Departing user’s eduPersonAffiliation must change promptly
Self-assessment of the requirements is allowed, but it must be documented.
History of edits
First version from Peter Solagna 30-09-2016