...
Of all processes described in "8.2 Credential management phase" - only these 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:
...
I_FACTOR_DELIVERY
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; alternatively, this can be done during the vetting phase.
I_ARRANGE_VETTING (optional)
Optional detailing of vetting. E-mail, initiation application or other channel is used to communicate a code, appointment details or other relevant information. May include several steps:
...
- 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 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 application is not eligible 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 may done by the applicant or by the service or operator check of the code 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, in the case of human-to-human interaction may be a softer start of vetting than to immediately demand V_PRESENT_PROOF.
V_PRESENT_PROOF
...
- .
V_CREATE_DIGITAL_IDENTITY (optional)
Only if the applicant does not already possess the 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, . Usually done before V_VERIFY_IDENTITY in order to allow parallelism at the service desk; should be undo-able if V_VERIFY_IDENTITY fails. 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.
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 → refer to I_FACTOR_DELIVERY?
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
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.
...
Effect on LoA: not applicable
C_USE_NEW_FACTOR (optional) DEFINED IN C
Making sure that the applicant possesses the new factor and is able to use it. This could 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.
...