Started with SURF's "Remote vetting for SURFconext Strong Authentication" descriptions of RV flows.
The content was refactored with ITU-T X.1254/ ISO/IEC 29115 recommendation "Entity authentication assurance framework" as a conceptual basis. Publicly available and influential.
The following generalised functional units (actions) serve to design and implement the vetting scenarios for second factor and multifactor authentication that fulfil some of ITU-T X.1254 entity authentication assurance framework processes. The following processes from its "8.1 Enrollment phase" are to be covered:
- 8.1.1 Application and initiation
- 8.1.2 Identity proofing and identity information verification
- 8.1.3 Record-keeping/recording
"8.1.4 Registration" is omitted as it is related with (later) use of services or resources.
Of all processes described in "8.2 Credential management phase" - only some are addressed here, as they are related with initialisation and issuance of the authentication factors, which, in our scenarios, are closely tied to identity proofing and verification:
- 8.2.1 Credential creation
- 8.2.1.1 Credential pre-processing
- 8.2.1.2 Credential initialization
- 8.2.1.3 Credential binding
- 8.2.1.1 Credential pre-processing
- 8.2.2 Credential issuance
- 8.2.3 Credential activation
- 8.2.7 Record-keeping
The names and descriptions used in these elaborations aim to be mappable to those processes and be terminologically compatible with ITU-T X.1254 and its definitions of terms. An additional specifics in relation the above-listed processes is that they focus on the credentials (sets of data supporting identity or entitlement claims), while our scenarios are focused on authentication factors (something specific that is possessed, known or inherent). The subject entities are referred to as applicants, who are the physical persons whose identity is to be authenticated.
The below descriptions our use our slightly shifted terminology, e.g. with factors, not credentials.
Actions are grouped in four sections: Common Actions, three general phases (Initiation, Verification, Binding).
Descriptions of actions are process and flow-oriented, not data-oriented. Inputs and outputs descriptions are therefore rather informal.
C: Common Actions
The actions listed here are common actions which may be used at multiple times at different stages and for various purposes.
C_USE_EXISTING_FACTOR Authenticate Using Existing Factor (Any alternative phrasing for _EXISTING?)
The applicant authenticates with his/her factor(s) already in place and function in the system. Username/password login is typically the first existing factor that is readily available.
This action may be used for multiple purposes:
Perform authentication with the existing factor(s) to prove knowledge/possession of the respective factor(s).
This action may also be used for checking the applicant's eligibility (see C_CHECK_ELIGIBILITY) based on the credentials used (e.g. by searching for a name or e-mail address in an LDAP directory) or the attributes (e.g. affiliation) which are sent in the authentication response.
Input: Credentials (e.g. username/password combination, certificate) provided by the user
Output: Authentication successful (yes/no), attributes is needed (e.g. affiliation)
C_SELECT_NEW_FACTOR Select Type of Factor to be Introduced
The applicant selects the type of the new factor to be introduced if there are several options. The offered options may depend on the place of the use, for example, a wider set of options may be available during initiation than with a particular subsequent (and possibly more specific) vetting and verification, where these choices may be limited.
There may be different factor types, e.g. something you know/have/are, the applicant can choose from as well as multiple realization options/products per factor (e.g. YubiKey, Google Authenticator).
Input: List of possible factors provided by the user
Output: factor selected/assigned and known by the applicant or in possession of the applicant
C_USE_NEW_FACTOR Use Introduced Factor
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: new factor
Output: usage of factor took place (for various purposes)
C_CHECK_ELIGIBILITY Check Eligibility of Applicant
Check if the applicant is eligible to request an additional factor. For example, if there are some policy or contractual restrictions. Is the applicant associated with participating organisation and eligible for the offered delivery of the additional physical factor such as token?
Done by manual or automated check a directory, federated identity, or examination of a written institutional certificate.
Input: applicant's identifying information
Output: decision: eligible (yes/no)
I: Application and Initiation
The initial request for an additional authentication factor during which vetting arrangements are made. This initiation can be integrated with face-to-face vetting sessions (if allowed by the service policy) when the actions needed to link this phase and separate verification session would not be necessary. The dedicated actions in this phase are are I_SUPPLY_FACTOR and I_ARRANGE_VERIFICATION. In some cases, this phase may be initiated by the Applicant's organisation, not directly by the applicant itself.
Some actions from the Commons block are referenced here to give an example how Application and Initiation phase may take place in practice. They are marked as optional actions.
C_USE_EXISTING_FACTOR (optional) DEFINED IN C
Optional. Used to provide both information about user identity and initial proof (with presumably weaker assurance) that the applicant is who (s)he claims to be.
C_CHECK_ELIGIBILITY (optional, requiring C_USE_EXISTING_FACTOR) DEFINED IN C
Optional. Used to check whether the applicant is entitled to request the additional factor at the moment of application, as this may incur some costs or use of resources.
C_SELECT_NEW_FACTOR (optional) DEFINED IN C
Optional, if there are several options for factors that may be offered at the start. May affect the options to be used during the vetting phase.
I_SUPPLY_FACTOR (optional) Supply New Factor
Optional. The applicant may either use his/her own factor, get a factor assigned or buy a factor (token) from an external provider. In the latter case, the applicant may also provide the payment information and delivery address. This may even be as simple as a mere redirection to an external supplier.
If needed, this includes physical sending of the factor (typically a token) and delivery period warranty so that I_ARRANGE_VERIFICATION could be performed (unless C_USE_NEW_FACTOR is required before it). Otherwise, it may involve initialisation of the authenticator application or whatever is required to do so that it could be used during the rest of the scenario.
Input: already collected data useful in arranging the supply, as the applicant name or selected factor
Output: latest expected delivery date, optional deliverer and, ultimately, delivered factor, actual delivery date and its deliverer's confirmation
C_USE_NEW_FACTOR (optional) DEFINED IN C
Optional factor (token) use in order to confirm usability and possession by the applicant. This may be mandatory if the applicant is expected to possess a token at the time of application and initiation; alternatively, this can be done later.
I_ARRANGE_VERIFICATION (optional) Arrange Verification
Optional detailing of vetting between the applicant and verifier. E-mail, initiation application or other channel is used to communicate a code, appointment details or other relevant information. May include several steps:
- Creation of a (secret) code to be used at the start of the vetting procedure to identify the vetting request or the new factor used during initiation (C_USE_NEW_FACTOR).
- If e-mail is used for vetting arrangement, get applicant's e-mail address (e.g. from the IdP account data) or from the applicant.
- Optional location selection and/or scheduling of the vetting appointment, only if the load or the policy of the service (desk) require this.
- Provide vetting details over e-mail or through the application, with code in text or QR, email validation link, instructions, vetting application link, service desk contacts, address and appointment details, and whatever else is needed.
- Optional e-mail validation, if e-mail is required for further interaction, and if a valid e-mail address is not already accessible and assured/guaranteed from the IdP data provided upon the previously performed login with the existing factor (C_USE_EXISTING_FACTOR).
Input: information about the applicant factor type and factor instance (if it was available and used) or planned delivery, and applicant preferences/choice for the proofing and verification phase
Output: appointment, code, confirmation data and instructions for the applicant, database record on the appointment
V: Identity Proofing and Information Verification
Do the actual vetting by proofing the applicant's identity and verifying (or vetting) identity information. This may be performed by an external organisation or a separate internal service.
V_COMMENCE Begin Vetting (possibly by accessing and validating the prior request)
Set up the context for identity proofing and information verification by linking prior initiation or performing it if has not been done. Verify, resume, and potentially update the context established during the initiation, or do the key work that that is in it. For example, if the applicant is allowed to come to a service desk without prior registration, C_CHECK_ELIGIBILITY that is normally done during initiation still must be performed; this may be even necessary if some time has passed since the initiation. Other initiation elements related to scheduling of the appointment or linking of initiation and vetting, such as (secret) code creation are pointless, as the applicant is already present and available for vetting.
- Vetting may be rejected and applicant turned back if the applicant is not eligible (any more) or if the queue is too long or the necessary resources, staff or involved key services are not available at this point.
- Restoring of the information and context established during initiation may include C_USE_EXISTING_FACTOR or use of previously created code to identify the vetting request or the factor used during initiation.
- If the validity of the e-mail address is considered significant, a code or link may be used to make sure that the applicant's e-mail is valid and can be accessed by her.
- This setting up of the context of the applicant's request may be done by restoring it after the applicant, service or desk operator uses the code issued during the initiation. The code that links the applicant with the original application is particularly useful when the applicant does not possess or know the first factor (which may require V_CREATE_DIGITAL_IDENTITY) and is not able to perform C_USE_EXISTING_FACTOR.
- If some time has passed since initiation, it may be necessary to perform C_CHECK_ELIGIBILITY again, as the applicant situation with her organisation may have changed in the meantime. This check could be done based on performed C_USE_EXISTING_FACTOR or the verbally provided identifying information, which, in the case of human-to-human interaction may be a softer start of vetting than to immediately demand V_PRESENT_PROOF.
Input: information about the appointment (link or code)
Output: established or retrieved information about the applicant, appointment and factor, or rejection of further actions.
V_CREATE_DIGITAL_IDENTITY (optional) Create Digital Identity (for applicants without first factor)
Only if the applicant does not already possess the IdP identity (weak i.e. identity that can be only attested with the first factor). This is optional and often prohibited or discouraged and avoided except for those in need of assistance or VIP individuals. At a service desk, this is to be done before V_CHECK_PROOF in order to allow parallelism; should be undo-able if any of checks before V_RECORD_CHECKS fail. This includes the check of the alignment with the enforced policies, informing of the applicant about the rules associated with this factor, creation of the username and the password, and providing the applicant with them.
This action should be invalidated if any of the following enrollment actions fails during both vetting and binding phases.
Input: applicant data needed for the IdP
Output: digital identity created with the IdP, possibly with a flag relation and against misuse if the checks fail, the applicant is able to use it during the rest of the process
V_PRESENT_PROOF Presents Proof of Identity
The applicant presents proof of identity, typically a sanctioned type of picture ID doc with demographic and biometric data.
C_SELECT_NEW_FACTOR (optional) DEFINED IN C
Optional - change of the factor the applicant has already applied for is quite unlikely but this may offer some flexibility by modifying the original choice made during the initiation.
V_HAND_OVER_FACTOR (optional) Hand Over Factor (to applicant)
Optional, if the factor such as token is immediately provided, e.g. by the service desk. Like I_SUPPLY_FACTOR, it can also include an immediate monetary transaction. Recording of handover is probably unnecessary, as the service/operator is in the possession of a proof (obtained with V_PRESENT_PROOF), so there is no risk of an irremediable situation or that the applicant would flee with the factor before C_USE_NEW_FACTOR.
Input: available factor, potentially money covering the costs
Output: factor handover record
V_CHECK_PROOF (Local) Check of the Presented Proof
Detailed (local) check of ID validity and match with the person of the applicant. Compare the claimed identity (information) which is transmitted by the applicant or system with the applicant's identity proof and the actual person.
Read and inspect the ID doc, compare the name with the vetting request, check ID security features, optionally electronically read the ID doc, compare photo/biometrics match with the person.
For online mechanisms, a separate liveness check may be needed to match with the real-world person.
V_EXTERNAL_CHECK (optional) Check External Validity
Check user's identity proof (e.g. national ID document, employee ID card) against its original source (such as issuing authority) or an official register for validity.
Make sure the identity proof is not expired, revoked or invalid.
Input: user's identity proof
Output: verified identity proof
Effect on LoA: typically higher LoA require this action
V_CHECK_LIVENESS (optional) 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. Otherwise implied by V_CHECK_PROOF conducted with the user.
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 means that show liveness
Output: liveness verified
V_RECORD_CHECKS (optional) Record Identity Proof
Optional record for audit purposes is produced, for example, by recording the last 6 digits of the number of the presented national ID document, but may also include other evidence on performed checks. However, the verifier should avoid the recording of excess personal data, including photos of the person or ID document.
A record should be made even if some of checks failed. If any of checks verification failed, V_CREATE_DIGITAL_IDENTITY may need to be undone, and the applicant may need be requested to return the token provided in V_HAND_OVER_FACTOR or even I_SUPPLY_FACTOR.
Input: identity proof
Output: record
C_USE_NEW_FACTOR (optional) DEFINED IN C
Making sure that the applicant knows/possesses/inherits the new factor and is able to use it. Or in case of preregistration make sure that all performed actions involving the new factor were with the same instance of the factor, as the used new token will be bound to the applicant's digital identity. This step should be performed by the applicant and therefore may require some time to complete, and thus it could be done by the user in parallel with V_CHECK_PROOF, V_EXTERNAL_CHECK and V_CHECK_LIVENESS. It may be preceded with C_USE_EXISTING_FACTOR it if has not been already performed. This may be omitted if C_USE_NEW_FACTOR was done during initiation.
This may be required if it includes personalisation of the factor.
V_CONCLUDE Conclude Verification
If the entire verification was successful, the concluding record for the initiation of factor binding is produced. This factor will be bound and activated after all prior steps of identity proofing and information verification are completed with success, so the record about it and its association with the applicant's digital identity is saved at this point. Since the different entities/providers may be responsible for verification and binding, and the verifier is typically engaged by the entity responsible for the long-term identity and credential management (IdP), the verifier will do it through a notification or by submitting the corresponding entry/record into the IdP system. In addition, the verifier can make an internal record about the creation of this entry, possibly also with details about performed C_USE_NEW_FACTOR.
Input: success and details from other steps of the verification phase
Output: the data needed for binding - digital ID of applicant, confirmation of verified identity, factor information
B: Factor Binding and Activation
Establishment of an operational link between the identity of the user and factor.
B_FACTOR_AND_ID Bind Factor to Digital ID
Create a long-term binding between the introduced factor and the digital ID of the user based on verified user identity.
Input: digital ID of applicant, confirmation of verified identity, factor information
Output: binding between digital ID and factor
B_ACTIVATE (optional) Activate Binding of Digital ID and New Factor
Activate the binding of the digital ID of the user and the new factor. The new factor may need to be unlocked, enabled or otherwise modified so that it can be used in regular authentications. For example, it may be in a state in which it was personalised and populated with all needed data but still marked as "not activated", which allows authentications with target services to fail even without contacting the factor issuer or IdP.
Input: binding between digital ID and factor
Output: decision: activation successful/unsuccessful
B_CONFIRMATION Inform User about Factor Activation
Inform the user about the correct/incorrect activation of the factor.
In case the factor activation was successful, the applicant can now authenticate using more than one factor.
Input: result of factor activation (positive/negative)
Output: message to the applicant
Detailed Attributes
- Additional implementations specific options or constrains
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...
I Optional initial vetting request registration during which vetting arrangements are made, if needed
I_AUTHORIZE (optional)
?_AUTHENTICATE 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_GET_EMAIL_ADDRESS If e-mail is used, from the IdP account data or applicant herself
I_MAKE_APPOINTMENT Optional scheduling of the vetting, only if the load at the service desk requires this
I_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
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 from the IdP data upon password login
V Do the vetting
V_NEGOTIATE (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 applicant
V_CHECK_ELIGIBILITY Same as V_CHECK_ELIGIBILITY. Even if I_ELIGIBILITY_CHECK was performed, the applicant situation may change in the meantime; may include I_AUTHENTICATION, check/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 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)
C_SELECT_FACTOR defined at C
V_HAND_OVER_FACTOR optional (if the token is provided by the service desk)
V_APPLICANT_IDENTITY detailed check of ID validity and match with the person
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 V_VET_ PROOF conducted with the user
V_RECORD_PROOF_AUDIT_DATA optional, typically by recording the last digits of ID doc number (avoid recording excess personal data, photos of the person or ID doc)
V_USE_TOKEN if HAND_OVER_TOKEN, done by the user in parallel with V_VET_APPLICANT_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_RECORD if both V_VET_APPLICANT_IDENTITY and V_USE_TOKEN if HAND_OVER_TOKEN were successful, otherwise reverse V_CREATE_DIGITAL_IDENTITY
B I would move F_SELECTION DEFINED and F_AUTHENTICATION earlier
2---------------------------
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???
- Code (e.g. QR-Code)
- Appointment
V Vetting/Vet
- 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 -------------------------------
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 of an additional factor.
Note: * is used as a wildcard. Set the appropriate value which applies to the specific action.
1F: may be used to indicate that a specific action refers to the first factor
2F: may be used to indicate that a specific action refers to the second factor
I_REQUEST Factor Request
In order to request an additional factor the applicant provides user information.
There are multiple options to realize this subactivity, e.g.: using federated login, e-mail, showing up at an registration desk, etc.
Input: user information (e.g. name, affiliation)
Output: factor request
I_SELECTION User Selects Factor
User selects a new factor/authenticator for multi factor authentication.
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
Output: factor selected/assigned and known/in possession/... by the user
REFERENCED FROM: B
*F_AUTHENTICATION
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.
(Optional) V_SCHEDULE 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
V_PROOF???
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:
V_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: ???
(Optional) V_SOURCE
Check user's identity proof (e.g. national ID document, employee ID card) against its original source for validity.
Make sure the identity proof is not expired/revooked/invalid/...
Input: user's identity proof
Output: verified identity proof
Effect on LoA: typically higher LoA require this action
V_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
B Binding
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 introdcued factor and the digital ID of the user based on a verified user identity.
Input: verified user identity, digital ID of user, factor
Output: binding between digital ID and factor
B_ACTIVATE Activate Binding of Digital ID and New Factor
Activate the binding of the digital ID of the user and the new factor.
This action is triggered by the registration authority.
Input: binding between digital ID and factor
Output: decision: activation successful/unsuccessful
B_CONFIRMATION Inform User about Factor Activation
Inform the user about the correct or incorrect activation of the factor.
In case the factor activation was successful the user can now authenticate using more than one factor.
This action is triggered by the registration authority.
Input: result of factor activation (positive/negative)
Output: message to user
------------------------------------------------------ Template for providing example realization options ---------------------------------------------------------------------
Example realization options
...
...
Federated Login
...
Short description
...
Federated login is used to provide user information
...
Input
...
User information (e.g. name, email, organization) typically via a SAML assertion
...
Output
...
Factor request
...
Advantages
...
Drawbacks/Risks
...
Mapping
I (Identity/Identification)
F (Factor) → 1F if first factor, 2F if second factor
...
Mandatory/optional?
(typically)
...
Input
(typically)
...
Output
(typically)
...
(Security) risks if omitted
(general)
...
Dependencies
(could be quite specific)
...
Increases/Decreases LoA
(general)
...
1.0) Should we have a first factor authentication subactivity here as a gatekeeper for "User provides user info"
FRq.UI 1.1) User provides user info
...
F_request
(e.g. 2F_request if second factor is requested)
...
- First check to be entitled to register 2FA token (e.g. federated login, email address is present which is associated with user/org. LDAP)
...
FReg.Authc 2.2) User performs authentication with that factor for binding and to prove possession/knowledge/...
...
Ident.Sched 3.0) Identification session arrangement and scheduling (!optional)
...
I_checkEligibility
1F_authenticate
...
Ident.UVet 3.3) Vet identity of user
...
Ident.UVet.ULive 3.3.2) Perform Liveness Check
(e.g. ID doc photo vs. real life face/ selfie)
...
FBind.DigID 4.2) Bind factor to digital ID
...
mandatory,
may already be performed in step 2
precondition: successful 3.2.1)
...
F_activate
F_record
...
mandatory
precondition: successful 3.2.1
...
federated login
...
(checked in 1.1 via login)
...