Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The names and descriptions used in these elaborations aim to be mappable to those processes and be terminologically compatible with ITU-T X.1254 and its definitions of terms. An additional specifics in relation the above-listed processes is that they focus on the credentials (sets of data supportingidentity supporting identity or entitlement claims), while our scenarios are focused on authentication factors (something specific that is possessed, known or inherent). The subject entities are referred to as applicants, who are the physical persons whose identity is to be authenticated.

...

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 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.

...

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.

...

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.

V_PREREGISTER_FACTOR

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_DIGITAL_ID Bind factor to digital ID (or B_FACTOR_AND_ID?)

Create a long term binding between the introduced factor and the digital ID of the user based on verified user identity.

...

Activate the binding of the digital ID of the user and the new factor. Explain why activation is needed after binding...

This action is triggered by the registration authority.

...