1---
V Do the actual vetting actual vetting by proofing the applicants identity and verifying identity information
V_
...
COMMENCE
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, the key elements of the initiation still must be performed, such as C_CHECK_ELIGIBILITY and C_SELECT_NEW_FACTOR
...
; 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 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 e-mail address is consireded significamt, a code or link may be used to make sure that the aplicant's e-mail is valid and can be accessed by her.
- This may done by the applicant or by the service or operator check of the code
...
C_CONFIRM_AVAILABILITY The vetting can be rejected if the service desk operator or front or back-end services are not available
...
- issued during the initiation and that is now provided by the applicant.
...
- The code is used to link the
...
- applicant with the original application,
...
- it is particularly useful when the applicant does not possess or know the first factor
...
- 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 may be a softwer to start the things going than to do this after V_PRESENT_PROOF right away
...
- .
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
...
Only if the applicant does not already possess IdP identity (weak or 1st factor identity). This is optional and often prohibited or or discouraged and avoided except for those in need of assistance or VIP individuals, 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. This includes 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)
C_SELECT_NEW_FACTOR DEFINED IN C d at C quite unlikely but may offer some flexibility by modifying the original choice made during the initiation
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
...
The following generalised functional units (actions) serve to design and implement the vetting scenarios for second factor and multifactor authentication that fulfill some of ITU-T X.1254 entity authentication assurance framework processes. The following processes from its "8.1 Enrolment Enrollment phase" are to be covered:
...
- Creation of the (secret) code to be used a the start of vetting to identify the registered vetting request request or while using the new factor used during duringinitiation.
- If e-mail is used, get applicant's e-mail address 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 written or QR code, email validation link, instructions, vetting application link, service desk contacts, address and appointment details, and whatever else is needed.
- Optional e-mail validation, if an 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 provide upon the previously performed login with the existing factor.
...