1--- Structure based on Flow: SURFnet 4.8-9 Registration Desk (Self-service token registration) and Flow: SURFnet 4.4 Mobile Application with Optical Scan + NFC +Selfie, to be combined with Jule's detailed structure below...
IInitiate (U - is User the word? Applicant) optional Optional initial vetting request registration during which vetting arrangements are made, if needed
I_AUTHORIZATION ?_?? (optional)
V_AUTHENTICATE
U_ELIGIBILITY_CHECK
sending the token
...
?_AUTHENTICATION typically a username/password login
I_CHECK_ELIGIBILITY Is the applicant associated with participating organisation and eligible for the estrangement of 2FA, if there are restrictions
I_SELECT_FACTOR if there are several options
I_REQUEST_FACTOR the applicant must also provide the delivery address
I_FACTOR_DELIVERY Optional sending the physical factor (typically a token), if such is used, and if this is a part of the provided service
I_ARRANGE_VETTING Optional, only if the e-mail is used for to communicate the code or appointment details or other relevant interaction, when this could be piggybacked to it)
I_PREREGISTER_FACTOR (optional) factor (token) preregistration, if the applicant is expected to possess a token at the time of registration
...
; alternatively, this is done during the vetting
I_CREATE_CODE Used for later token activation or to identify the registered vetting application at the beginning of the actual vetting
I
U_CREATE_VETTING_CODE (typically for later token activation, but could also to identify user registration at the start of vetting)
U_ARRANGE_VETTING (optional, only if the e-mail used scheduling, appointment, activation code communication or other relevant interaction, when this could be piggybacked to it)
U_GET_EMAIL_ADDRESS if If e-mail is used, from the IdP account data or userapplicant herself
UI_SCHEDULE_VETTING optionalMAKE_APPOINTMENT Optional scheduling of the vetting, only if the load at the service desk requires this
UI_COMMUNICATE_VETTING_INFO with token activation or QR code, email validation link, instructions, application link, service desk contacts or address and appointment details, or whatever is needed
UI_VALIDATE_EMAIL optionalOptional, if an e-mail is required for further interaction and a valid e-mail address is not already assured/guaranteed and accessible from the IdP data upon password login
...
V_USE_VETTING_CODE if there was U_CREATE_VETTING_CODE - service or operator check the code provided by the userapplicant
V_CHECK_ELIGIBILITY optional, if USame as V_CHECK_ELIGIBILITY. Even if I_ELIGIBILITY_CHECK was not performed, or if it was not sufficientthe applicant situation may change in the meantime; may include VI_AUTHENTICATEAUTHENTICATION, chechcheck/examination of a directory, federated identity, or written institutional certificate.
V_PRESENT_PROOF applicant presents a proof of identity, typically a sanctioned type of picture ID doc with demographic and biometric data
(V_CREATE_DIGITAL_IDENTITY optional, only if the user applicant does not already possess IdP identity (weak or 1st factor identity), done before V_VET_USERAPPLICANT_IDENTITY in order to allow parallelism at the service desk; should be undo-able if V_VET_USERAPPLICANT_IDENTITY fails. Includes creation of the username and the password and check of their alignment with the enforced policies)
...
V_HAND_OVER_FACTOR optional , (if the token is provided by the service desk)
V_VETAPPLICANT_USER_IDENTITY detailed check of ID validity and match with the person
...
V_RECORD_PROOF_AUDIT_DATA optional, typicaly typically by recording the last digits of ID doc number (avoid recording excess personal data, photots photos of the person or ID doc)
V_USE_TOKEN if HAND_OVER_TOKEN, done by the user in parallel with V_VET_USERAPPLICANT_IDENTITY
V_PASSWORD_AUTHENTICATION like U_PASSWORD_AUTHENTICATION
V_REGISTER_TOKEN like U_INTRODUCE_FACTOR could be standalone even without V_HAND_OVER_TOKEN, but unnecessary with U_INTRODUCE_FACTOR/U_PREREGISTER_TOKEN and V_USE_VETTING_CODE; the used token will be later bound to digital identity
V_VET_RECORD if both V_VET_USERAPPLICANT_IDENTITY and V_USE_TOKEN if if HAND_OVER_TOKEN were successful, otherwise reverse V_CREATE_DIGITAL_IDENTITY
B_BIND B I would move F_SELECTION DEFINED and F_AUTHENTICATION earlier
2---------------------------new Structure based on yesterdays discussion:
new Structure based on yesterdays discussion:
C Commons
- Authenticate Exiting Factor
- Use Introduced Factor
- Eligibility check
I Initiation/Initiate → what is needed here?
- Request
- Factorselection???Appointment
- Code ???
A Authentication/Authenticate
- Factor1
- Factor2
- FactorN
- Code (e.g. QR-Code)
- Appointment
V Vetting/Vet
- Eligiblity
- Proof
- Liveness
- Source
- Record
- 2 different records
B Binding/Bind
- DigitalID
- Activation
- Confirmation
3 -------------------------------
...
Effect on LoA: not applicable
V_ELIBILITY ELIGIBILITY Check Eligibility of User
...
Create a binding between the newly selected factor and the digitalID digital ID of the user based on a verified user identity.
...
Output: decision: activation successful/unsuccessful
B_RECORD Create Record of Binding → delete???
#short description
B_CONFIRMATION Inform User about Factor Activation
...