--- 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_REGISTRERREGISTER/INITIATE (U - is User the word? or I=INITIATE R=REQUEST/REGISTER)
U_PASSWORD_AUTHENTICATION
...
U_INTRODUCE_FACTOR (could be alternatively done during vetting) (token preregistration)
U_CREATE_VETTING_CODE (typically for later token activation, but could also to identify user registration at the start of vetting)
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_VALIDATE/BIND_EMAIL (optional, if a valid e-mail address is not already assured/guaranteed and accessible from the IdP data upon password login)
V_VET
V_NEGOTIATE/INITIATE (optional, related to U_SCHEDULE_VETTING)
V_CONFIRM_AVAILABILITY can be rejected if the service desk operator or front or back-end services are not available
V_USE_VETTING_CODE if there was U_CREATE_VETTING_CODE - service or operator check the code provided by the user
V_CHECK_ELIGIBILITY optional, if U_ELIGIBILITY_CHECK was not performed, or if it was not sufficient; may include chech/examination of a firectory, federated identity, or written institutional certificate
V_VET_USER_IDENTITY
V_PRESENT_PROOF typically picture ID doc with demographic and biometric data
V_VET_ PROOF read and inspect the ID doc, compare the user name with the vetting request, check ID security features, optionally electronically read the ID doc, optionally externally check doc validity, compare photo/biometrics match with the person,
V_CHECK_LIVENESS optional, in case online identity vetting, otherwise implied by live
---
*F Factor Initiation?/(pre-)registration?
Short descriptionInitiate the registration of an additional factor.
Note: * is used as a wildcard. Set the appropriate value which applies to the specific action.
...
2F: may be used to indicate that a specific action refers to the second factor
AttributeX: Some later detailed attributes could come here.
*F_REQUEST Factor Request
...
There may be different factor (types), e.g. something you know/have/are, the user can choose from
as well as multiple realization options/products per factor (e.g. Yubikey, Google Authenticator), here referred as authenticators.
Input: List of possible factors/authenticators
...
REFERENCED FROM: B
*F_AUTHENTICATION
User performs authentication with newly requested factor for binding and to prove possession/knowledge/inheritance/...
generic action. action may be used for 1F, 2F,... authentication
authenticates with a specific factor. This action may be used for multiple purposes:
This action may be used for the first factor (i.e. 1F_AUTHENTICATE) in order to check first factor knowledge/possession/inheritance/... or as a mean to provide user information (i.e. sub action of 2F_REQUEST).
The action may also be used for the second/third/... factor to create an initial binding between digital ID and factor. This initial binding typically needs to be verified requiring identity vetting action may have multiple purposes, e.g. serves as intial binding between digitalID and factor (reference to B_DIGITALID ?) This initial binding may need to be verified requiring some user interaction before it is put into effect.
REFERENCED FROM: B
check possession of first factor → include activity, see 3.1
...
Compare 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:
...
Output: verified identity proof
Effect on LoA: ??? typically higher LoA require this action
I_VET_RECORD Record Identity Proof
...
Establishment of a binding between the digital identity of the user and factor
AttributeX: Some later detailed attributes could come here.
AttributeY: Some later detailed attributes could come here.
(Optional) F_SELECTION DEFINED AT: F
...