--- 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...
U_REGISTRER/INITIATE (U - is User the word?)
U_PASSWORD_AUTHENTICATION
U_ELIGIBILITY_CHECK
U_INTRODUCE_FACTOR ( could be alternatively done during vetting) (token preregistration)
U_COMMUNICATE_VETTING_SPECIFICS (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 (from IdP account data or user)
U_SCHEDULE_VETTING (optional, only if the load at the service desk requires this)
U_SEND_VETTING_INTRO_MESSAGE (with token activation or QR code, email validation link, instructions, application link, service desk contacts or address and appointment details, or whatever is needed)
U_VALIDATE/BIND_EMAIL (optional, if a valid e-mail address is not already assured/guaranteed and accessible from the IdP data upon password login)
---
*F Factor Initiation?/(pre-)registration?
...
Input: user information (e.g. name, affiliation)
Output: factor request
*F_SELECTION SELECTION User Selects Factor
User selects a new factor/authenticator for multi factor authentication.
...
Output: factor selected/assigned and known/in possession/... by the user
REFERENCED FROM: B
*F_AUTHENTICATIONAUTHENTICATION
User performs authentication with newly requested factor for binding and to prove possession/knowledge/inheritance/...
...
Capture and verify information about a user for identification.AttributeX: Some later detailed attributes could come here.
AttributeY: Some later detailed attributes could come here.
(Optional) I_SCHEDULING SCHEDULING Identification session arrangement and scheduling
Schedule an identification session in order to identify the user.
Optional action. Real-time interaction may not be required.
Input:
Output: identity vetting appointment
Effect on LoA: not applicable
I_ELIBILITYCHECK CHECK_ELIBILITYCHECK Check Eligibility of User
Check if the user is eligible to request an additional factor.
This action may be an implicit sub action of another action (e.g. *F_REQUEST using federated login).
Input: user information
Output: decision: eligible (yes/no)
Effect on LoA: not applicable
I_VET Vet Identity of User
Vet the real-world identity of the user.
This action consists of multiple sub actions.#short description
I_VET_PROOF???
Compare claimed/transmitted/spoken information the claimed identity (information) which is transmitted by the user or system with user's identity proof (e.g. ID doc, activation code).
Input:
Output:
Effect on LoA:
I_VET_LIVENESS Perform Liveness Check
In case online identity vetting mechanisms are used (such as video identification, online document upload) a liveness check may be performed to prevent fraud.
Example1: Show ID document besides the head to prove ID document and holder match.
Example2: Upload ID document and real-time recorded selfie.
Input: any mean to show liveness
Output:
Effect on LoA: ??? (e.g. ID doc photo vs. real life face/ selfie)
(Optional) I_VET_SOURCE
Check user's identity proof with proof (e.g. national ID document, employee ID card) against its original source for validity (not expired, retired,..).
Make sure the identity proof is not expired/revooked/invalid/...
Input: user's identity proof
Output: verified identity proof
Effect on LoA: ???
I_VET_RECORD Record Identity Proof
For accountability purposes (parts of) the identity proof (e.g. last 6 digits of national ID document) is recorded.
Input: identity proof
Output: record
Effect on LoA: not applicable#short description
B Binding
Establishment of a binding between the digital identity of the user and factor
...