EGI-Check-in Assessment

	A	B	C
1	Requirement	Comment	Score
2	VO Membership Management Overview
3	- Membership requests must be possible with different user owned credential types (e.g. SAML, certificate, OIDC/OAuth2) as defined by the VO	Yes (currently facebook, google, linkedin etc)
4	- VOs should be able to know the level of assurance of the VO identity (identity & authentication method)	Could support RAF, needs to be defined
5	- Users must be able to link multiple accounts, to cope with e.g. home organisation changes	Yes
6	- Periodic membership renewal should be supported, as defined by policy	Yes, policies should be defined. Currently based on HR DB & VOMS yearly policy
7	- Periodic credential verification should be supported, as defined by policy	Refresh tokens Yes
8	- Periodic AUP Signing should be supported, as defined by policy, including:
9	- user suspension upon failure to sign	Yes
10	- controlled delegation and consent	??
11	- Integration of additional trusted data sources must be supported (e.g. Institute Affiliation expiry from CERN HR DB)	In progress
12	- VO managers must be able to overwrite the information from integrated data sources	Yes
13	- For LHC VOs, the option to leverage CERN Infrastructure must be supported, such as:
14	- Integrated with trusted identity vetting process, e.g. CERN HR for WLCG	In progress
15	- Membership expiration based on home institute affiliation	In progress
16	- CERN SSO as a trusted IdP	To Do
17	- VO management should provide a process that, given a token or identifier, can resolve user attributes. This should be restricted to VO and Infrastructure level use.	Yes
18	- Hierarchical groups should be supported.	Yes
19	Required User Attributes (for the VO to operate)
20	- First Name & Last Name (or DisplayName)	Yes
21	- Email	Yes
22	- UniqueID of incoming credential (for each credential) (combination of Identity Provider and credential ID must be unique)	Yes
23	- Unique VO User ID (e.g. for LHC VOs: CERN ID for link to HR db) (scope is VO)	Yes
24	- VO name	Yes
25	- Authorization attributes (groups/roles/generics)	Yes
26	User Credential types (i.e. Authentication, not server-server auth tokens)
27	- Federated Credentials such as SAML/OIDC/OAuth2.0/Certificates	Yes (certificates through IGTF proxy)
28	- Flexibility to enable a trusted IdP where appropriate, e.g. CERN SSO	To Do
29	- All credentials must be able to satisfy minimum requirements for Assurance, VOs should be able to select which specific Identity Providers they enable	Needs thinking (could just have authentication fail)
30	- Combined assurance of identity and VO processes must meet equivalent assurance for x509 IGTF:
31	- IdP meets security standards (e.g. via Sirtfi)	Yes, configurable
32	- IdP releases necessary attributes (eg. R&S)	Yes, configurable
33	- REFEDS assurance framework	In progress
34	- Step-up for critical services e.g. 2FA	No
35	Token provisioning workflow
36	- AuthZ attribute selection by the user must be possible (i.e. active role selection)	In progress
37	- Token renewal frequency and process should be manageable without additional training	Yes
38	Usability
39	- Documentation should be provided and maintained	Yes, https://wiki.egi.eu/wiki/AAI
40	- Bulk actions for VO Managers and Users should be enabled where appropriate	Yes, multiple users to group. Other tbc
41	Service Providers
42	Service Requirements Overview
43	- Aim at simplicity and ease of implementation	Yes
44	- Use existing, standard approaches	JWT
45	- Authorization schemas should be consistent between VOs	JWT
46	- All Tokens:
47	- Tokens must be supported on web and non-web	Yes
48	- Must be able to determine the token issuer	Yes (JWT)
49	- Identity/Access Tokens:
50	- Must be short lived	JWT
51	- Should be possible to transparently provision the user with the required token	SSH flow to get certificate & tokens. & Device code flow
52	- Users must be able to allow services constrained delegation	Token exchange
53	- Should include sufficient information to allow decentralised verification	JWT
54	- Refresh Tokens:
55	- Must be revocable	Yes
56	Required User Attributes (for the services to operate)
57	- Traceability information, i.e. potentially Semi-Opaque IDs that can be resolved to an identity for security purposes	Comanage provides algorithm for sub
58	- At least one of:
59	- Capabilities	Mapped from groups to capabilities
60	- Authorisation attributes, i.e. Roles/Groups	Yes, but not roles
61	- Additional identity information should be supported, as required by policy	Configurable (JWT)
62	Non-web
63	- Users should not have to manage x509 certificates or other identity tokens themselves in addition to their login session	Yes
64	- AuthZ attributes should be consistent across WLCG web and non-web services	JWT
65	Operational Requirements
66	- Access token lifetime < operational response minimum time, as defined by policy and in line with standard recommendations	JWT
67	- Must support revocation of long lived tokens	Yes
68	- Suspension:
69	- Blocking of individual VO Users across all services/subset must be possible by a VO and/or the Infrastructure (i.e. Security Team) within a timeframe defined by policy	Yes
70	- Sites/Services must be able to block (potentially opaque) VO Users locally, and inform relevant parties (e.g. Infrastructure security or VO management) as defined by policy	NA
71	Change Management
72	- A smooth transition path should be defined, including backwards compatibility for a necessary timeframe	Backwards compatible apart from Roles (WIP)
73
74
75
76
77	EGI-Check-in Demo videos	In the following url we have uploaded small videos that demonstrate the various functionalities of the framework as configured for the case of WLCG Pilot
78		https://www.dropbox.com/sh/0u9d5fzuxrjyu3k/AAClKTVLpJRC5YN2kh0JlKsGa?dl=0
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100