Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "EGI-Engage:TASK JRA1.1 Proposal for Levels of Assurance"

From EGIWiki
Jump to navigation Jump to search
(→‎LoA: B: fix link for Dogwood)
 
(22 intermediate revisions by 2 users not shown)
Line 9: Line 9:
This section contains the proposed categories of level of assurance as interpreted and published by the EGI AAI Proxy (CheckIn service).
This section contains the proposed categories of level of assurance as interpreted and published by the EGI AAI Proxy (CheckIn service).


== LoA: 0 ==
== LoA: null ==


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 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 catogory 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.  


== LoA: 1 ==
'''For this category no LoA is assigned'''


This category groups the credentials that are usable in a federated environment, but may require additional attributes to be used in all applications.The credentials with LoA:1 or higher can access the online CA "RC Auth" to retreive X.509 proxy.
== LoA: A  ==


Requirements:
This category groups accounts coming from Identity Providers, which participate in one of the eduGAIN Federations
#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 non-re assignable identifier


== LoA: 2 ==
<br>


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.
'''This category is expressed with LoA A'''
The requirements are the following:


== LoA: B  ==


#The accounts in the Home Organisations must each belong to a known individual person
This category groups accounts coming from Identity Providers, which support&nbsp;[https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf SIRTFI] and the [https://refeds.org/wp-content/uploads/2016/09/ENTCAT-RANDS-v1.3.pdf Research &amp; Scholarship Entity Category]<br>
#*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


<br> '''This category is expressed with LoA B and is equivalent to [https://www.igtf.net/ap/authn-assurance/igtf-authn-assurance-1.0.pdf IGTF DOGWOOD]'''<span style="font-size: 13.28px;">&nbsp;</span>'''<span style="font-size: 13.28px;">and meets the&nbsp;</span><span style="font-size: 13.28px;">&nbsp;</span>'''[https://aarc-project.eu/wp-content/uploads/2015/11/MNA31-Minimum-LoA-level.pdf '''AARC Baseline Assurance''']


Self-assessment of the requirements is allowed, but it must be documented.
== LoA: C  ==


== LoA: 3 ==
This category groups accounts coming from Identity Providers, which fulfill the all the requiremens of LoA: B and in addition the meet the requirement of [https://www.igtf.net/ap/authn-assurance/igtf-authn-assurance-1.0.pdf IGTF BIRCH]
This category groups credentials with an higher LoA for both the authentication and the attributes distributed in the assertion. At the moment EGI does not have use cases for an higher LoA than #2 but some applications have stricter requirements and therefore a placeholder is created.
 
Service providers in EGI shall not expect LoA higher than #3
<br>
 
'''This category is expressed as LoA C and is equivalent to [https://www.igtf.net/ap/authn-assurance/igtf-authn-assurance-1.0.pdf IGTF BIRCH and CEDAR]'''


= References =
= References =
REF1: [https://aarc-project.eu/wp-content/uploads/2015/11/MNA31-Minimum-LoA-level.pdf AARC MNA3.1:Recommendations on Minimal Assurance Level Relevant for Low-risk Research Use Cases]
REF1: [https://aarc-project.eu/wp-content/uploads/2015/11/MNA31-Minimum-LoA-level.pdf AARC MNA3.1:Recommendations on Minimal Assurance Level Relevant for Low-risk Research Use Cases]
= Notes and comments =
Side discussion about LoA definitions
Currently we are using Low/Substantial/High:
https://wiki.egi.eu/wiki/AAI_guide_for_SPs#Level_of_Assurance
Proposal to use 4 levels:
* ZERO: Social IDs or self-registration
* LOW: IdP from federations in eduGAIN
* BASELINE: https://aarc-project.eu/wp-content/uploads/2015/11/MNA31-Minimum-LoA-level.pdf
* BIRCH: https://www.igtf.net/ap/authn-assurance/


= History of edits =  
= History of edits =  
First version from Peter Solagna 30-09-2016
First version from Peter Solagna 30-09-2016

Latest revision as of 23:01, 28 November 2016

EGI-Engage project: Main page WP1(NA1) WP3(JRA1) WP5(SA1) PMB Deliverables and Milestones Quality Plan Risk Plan Data Plan
Roles and
responsibilities
WP2(NA2) WP4(JRA2) WP6(SA2) AMB Software and services Metrics Project Office Procedures



Introduction

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).

LoA: null

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 catogory 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.

For this category no LoA is assigned

LoA: A

This category groups accounts coming from Identity Providers, which participate in one of the eduGAIN Federations


This category is expressed with LoA A

LoA: B

This category groups accounts coming from Identity Providers, which support SIRTFI and the Research & Scholarship Entity Category


This category is expressed with LoA B and is equivalent to IGTF DOGWOOD and meets the  AARC Baseline Assurance

LoA: C

This category groups accounts coming from Identity Providers, which fulfill the all the requiremens of LoA: B and in addition the meet the requirement of IGTF BIRCH


This category is expressed as LoA C and is equivalent to IGTF BIRCH and CEDAR

References

REF1: AARC MNA3.1:Recommendations on Minimal Assurance Level Relevant for Low-risk Research Use Cases

Notes and comments

Side discussion about LoA definitions

Currently we are using Low/Substantial/High:

https://wiki.egi.eu/wiki/AAI_guide_for_SPs#Level_of_Assurance

Proposal to use 4 levels:

History of edits

First version from Peter Solagna 30-09-2016