...
This action should be invalidated if any of the following enrollment actions fails during both vetting and binding phases.
V_PRESENT_PROOF → include in V_VET_PROOF?
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, if the factor such as token is provided by the service desk. Recording of handover is probably unnecessary, as the service/operator is in the possession a proof (it was 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.
V_PRESENT_PROOF
The applicant presents proof of identity, typically a sanctioned type of picture ID doc with demographic and biometric data.
V_VERIFY_IDENTITY →do we need subactions here?
Detailed 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.
- V_VET_ PROOF The applicant presents proof of identity, typically a sanctioned type of picture ID doc with demographic and biometric data. Then reading and inspecting 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.
(Optional)V_SOURCE (optional)
Check user's identity proof (e.g. national ID document, employee ID card) against its original source for validity.
...
Output: verified identity proof
Effect on LoA: typically higher LoA require this action
- Perform Liveness Check V_CHECK_LIVENESS optional, in case online identity vetting, otherwise implied by V_VET_ PROOF conducted with the user.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_VET_ 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_PROOF_AUDIT_DATA (optional) Record Identity Proof
Optional, typically by recording the last digits of ID doc number (avoid recording excess personal data, photos of the person or ID doc)
...
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 the factors match. This could be done by the user in parallel with V_VERIFY_IDENTITY. It may be preceded with C_USE_EXISTING_FACTOR it if has not been already performed. This may be avoided if C_USE_NEW_FACTOR was done during initiation or implied by a record on V_HAND_OVER_FACTOR. The record about C_USE_NEW_FACTOR could be a standalone event of the vetting phase or even required if there was no V_HAND_OVER_TOKEN, but it may be unnecessary with the presence C_PREREGISTER_TOKEN and V_USE_VETTING_CODE; the used token will be later bound to digital identity.
V_PREREGISTER_FACTOR (optional) → this is no preregistration, rather POSTregistration
This factor will be later bound and activated, so the record about it and its association with the applicant's digital identity is saved. For this to happen, all prior steps of vetting should be completed with success.
B: Factor Binding and Activation
...