...
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 vetting the user was directed to at the initiation phasesubsequent (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).
...
Initial request for an additional authentication factor during which vetting arrangements are made.Optional actions in case This initiation can be integrated with face-to-face vetting will take place. If needed:
...
sessions (if allowed by the service policy), when the actions needed to link this phase and separate verification session would not be necessary. These actions are I_FACTOR_DELIVERY and I_ARRANGE_VETTING. Is some cases, this phase may need to be initiated by the Applicant's organisation, not directly by herself.
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_REQUESTSUPPLY_FACTOR (optional)
Optional. The applicant may also provide a delivery address and perhaps even pay for the factor, handling and delivery service. This may be even as simple as redirection to the external factor provider.
...
Optional sending or handing over of the physical factor (typically a token), if such is used, and if this is a part of the provided service.
....
C_USE_NEW_FACTOR (optional) DEFINED IN C
Optional factor (token) preregistration and binding with the request. If the applicant is expected to possess a token at the time of registration application and initiation; alternatively, this can be done during the vetting phase.
I_ARRANGE_VETTING (optional)
...
- Creation of a (secret) code to be used at the start of 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 writtencode in text 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 e-mail is required for further interactioninteraction, 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).
V: Identity Proofing and Information Verification
Do the actual vetting by proofing the applicant's identity and verifying (or vetting) identity information.
- Proof
- Liveness
- Source
- Record
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, the key elements of the C_CHECK_ELIGIBILITY that is normally done during initiation still must be performed, such as C_CHECK_ELIGIBILITY and C_SELECT_NEW_FACTOR; other ; this may be even necessary if some time has passes 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 backback if the application 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 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 or by the , service or desk operator check of uses the code issued during the initiation and that is now provided by the applicant. The code is used to link that links the applicant with the original application , it 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.
...
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.
...
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 → refer to I_FACTOR_DELIVERY?
Optional, if the factor such as token is provided by immediately provided, e.g. by the service desk. Like I_FACTOR_DELIVERY, 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 (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_VERIFY_IDENTITY →do we need subactions here?
CHECK_PROOF Local Check of the Presented Proof
Detailed local 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.
...
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 is needed.
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 a register for validity.
Make sure the identity proof is not expired/revoked/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, typically by recording the last digits of ID doc number (avoid recording excess personal data, photos of the person or ID doc)
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
C_USE_NEW_FACTOR (optional) DEFINED IN C
Making sure that 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 all performed actions involving the new factor were with the same instance of the factor, as the used token will be bound to digital identity. This step should be performed by the applicant and therefore may take some time to be performed, so could be done by the user in parallel with V_CHECK_PROOF, V_VERIFY_IDENTITY_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 avoided if C_USE_NEW_FACTOR was done during initiationor implied by a record on .
V_
...
PREREGISTER_FACTOR (optional) → FIND BETTER WORDINGV_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.
...