...
I Optional initial vetting request registration during which vetting arrangements are made, if needed
I_AUTHORIZATION AUTHORIZE (optional)
?_AUTHENTICATION AUTHENTICATE typically a username/password login
...
I_VALIDATE_EMAIL Optional, if an e-mail is required for further interaction and a valid e-mail address is not already accessible and assured/guaranteed and accessible from the IdP data upon password login
...
(V_CREATE_DIGITAL_IDENTITY optional, only if the applicant does not already possess IdP identity (weak or 1st factor identity), done before V_VET_APPLICANT_IDENTITY in order to allow parallelism at the service desk; should be undo-able if V_VET_APPLICANT_IDENTITY fails. Includes creation of the username and the password and check of their alignment with the enforced policies)
VC_SELECT_FACTOR defined at C
V_HAND_OVER_FACTOR optional (if the token is provided by the service desk)
...
- Proof
- Liveness
- Source
- Record
- 2 different records
B Binding/Bind (if Enrollment or Issuance are overloaded by the existing frameworks or often used with different meaning)
- DigitalID
- Activation
- Confirmation
3 -------------------------------
*F Factor Initiation?/(pre-)registration?
C Commons
#short description
C_AUTHN_??? Authenticate Existing Factor → TODO: short intuitive label
#short description
Input:
Output:
C_USE_??? Use Introduced Factor → TODO: short intuitive label
Usage of the introduced factor may serve multiple purposes at different stages.
E.g. Use introduced factor to test functioning, to prove knowledge/possession/inheritance/... or to make sure factors match.
Input:
Output:
C_ELIGIBILITYCHECK Check Eligiblity of Applicant
Check if the applicant is eligible to request an additional factor.
Input: user information
Output: decision: eligible (yes/no)
I Initiation?/(pre-)registration?
Initiate the registration Initiate 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
*FI_REQUEST Factor Request
In order to request an additional factor the applicant provides user information.
...
Input: user information (e.g. name, affiliation)
Output: factor request
*FI_SELECTION User Selects Factor
...
Output: factor selected/assigned and known/in possession/... by the user
REFERENCED FROM: B
*F_AUTHENTICATIONAUTHENTICATION
User 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. as a 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 the vetting of the user's identity before it is put into effect.
It may also be used to (cross-) check second/third/... factor knowledge/possession/inheritance/...
Input:
Output:
REFERENCED FROM: B
V Identity Vetting
Capture and verify information about a user for identification.
...
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
V_ELIGIBILITY 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
order to identify the user.
Optional action. Real-time interaction may not be required.
Input:
Output: identity vetting appointmentOutput: decision: eligible (yes/no)
Effect on LoA: not applicable
...
Establishment of a binding between the digital identity of the user and factor
(Optional) F_SELECTION DEFINED AT: F
Selection of a particular factor/authenticator may take place while or after identity vetting.
Besides the selection by the user an assignment of a factor/authenticator e.g. by the registration desk is possible, too.
Input: List of possible factors/authenticators
Output: factor selected/assigned and known/in possession/... by the user
B_DIGITALID Bind factor to digital ID
Create a binding between the newly selected introdcued factor and the digital ID of the user based on a verified user identity.
...
Output: binding between digital ID and factor
(Optional) *F_AUTHENTICATION DEFINED AT: F
Test authentication with factor to test functioning and to prove knowledge/possession/inheritance/...
In case preregistration took place, make sure the factors/authenticators match.
Input:
Output:
B_ACTIVATE Activate Binding of Digital ID and New Factor
...