...
Output: Authentication successful (yes/no), attributes is needed (e.g. affiliation)
C_SELECT_NEW_FACTOR !!do we need something here
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.
...
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. 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 the applicant itself.
C_USE_EXISTING_FACTOR (optional) DEFINED IN C !!do we need something here
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_SELECT_NEW_FACTOR (optional) DEFINED IN C !!do we need something here
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) !!do we need something here
Optional. The applicant may either use his/her own factor, get a factor assigned or buy a factor (token) from the external provider. In the latter case, the applicant may also provide the payment information and delivery address. This may even be as as simple as mere redirection to an external supplier.
...
C_USE_NEW_FACTOR (optional) DEFINED IN C !!do we need something here
Optional factor (token) preregistration and binding with the request. If 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_VETTING (optional) !!do we need something here
Optional detailing of vetting between the applicatn 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:
...
Do the actual vetting by proofing the applicant's identity and verifying (or vetting) identity information.
This may be perfomed by an outside organisation or a separate internal service.
- Proof
- Proof
- Liveness
- Source
- Record
V_COMMENCE Begin vettingVetting, possibly by accessing and validating the prior request !!too long?
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 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.
...
V_CREATE_DIGITAL_IDENTITY (optional) !!do we need something here
Only if the applicant does not already possess the IdP identity (weak or 1st factor identity). This is optional and often prohibited or discouraged and avoided except for those in need of assistance or VIP individuals. Usually done before V_CHECK_PROOF in order to allow parallelism at the service desk; should be undo-able if any of checks before V_PREREGISTER_FACTOR 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.
...
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!!do we need something here
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!!do we need something here
Optional, if the factor such as token is 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 (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.
...
C_USE_NEW_FACTOR (optional) DEFINED IN C !!do we need something here
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 token will be bound to the 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_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 initiation.
This may be required if it also includes personalisation of the factor.
V_PREREGISTER_FACTOR (optional) → B_FACTOR_AND_ID (optional) defined in B?
CONCLUDE !!do we need something here
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. For this to happen, all prior steps of vetting should be completed with success.s digital identity is to saved at his point. Since the different entities/providers may be responsible for verification and binding, and the verifier is typically engaged by the the entity responsible for the long-term identity and credential management, the verifier should notify it or submit the corresponding entry/record into its 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 user, confirmation of verified user identity, factor information
Effect on LoA: not applicable
B: Factor Binding and Activation
...
- Binding of factor and ID
- Activation
- Confirmation
B_FACTOR_AND_ID Bind factor 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: verified digital ID of user identity, digital ID confirmation of verified user 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 personalized and populated with all needed data, but still marked as "not activated", which allows authentications with target services to fail even without requiring them to contact contacting the factor issuer or IdP.
...