Page History

C Commons

• Authenticate Exiting Factor - One can not authenticate an authentication factor, but subjects with the factor! WITH? Or, even better, Use Exiting Factor?
• Use Introduced Factor
• Eligibility check

I Initiation/Initiate → what is needed here?

• Request
• Factor selection???
• Code (e.g. QR-Code)
• Appointment

V Vetting/Vet

• Proof
• Liveness
• Source
• Record
  • 2 different records

B  Factor Binding and Activation

• Digital ID
• Activation
• Confirmation

3 -------------------------------

The following generalised functional units (actions) serve to design and implement the vetting scenarios for second factor and multifactor authentication that fulfill fulfil some of ITU-T X.1254 entity authentication assurance framework processes. The following processes from its "8.1 Enrollment phase" are to be covered:

• 8.1.1 Application and initiation
  
• 8.1.2 Identity proofing and identity information verification
  
• 8.1.3 Record-keeping/recording
  

"8.1.4 Registration" is omitted as it is related with (later) use of services or resources.

Of all processes described "8.2 Credential management phase" - only these are addressed here, as they are related with initialisation and issuance of the authentication factors, which, in ours our scenarios, are closely tied to identity proofing and verification:

• 8.2.1 Credential creation
  
  • 8.2.1.1 Credential pre-processing
    
  • 8.2.1.2 Credential initialization
    
  • 8.2.1.3 Credential binding
    
• 8.2.2 Credential issuance
• 8.2.3 Credential activation
• 8.2.7 Record-keeping → do we need a "record"-activity for the binding/activiation activation process? → At several points and places for sure.
  

The used names and descriptions used in these elaborations aim to be mapable 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 we focus they focus on the credentials (sets of data supportingidentity or entitlement claims), while our scenarios are focused on authentication factors (something specific that is possessed, known or inherent), as opposed to of credentials (data sets that could be presented). The subject entities are referred to as applicants, who are the physical persons whose identity is to be authenticated.

C: Commons

#short description

• Use Exiting Factor
• Use Introduced Factor
• Eligibility check

C_USE_EXISTING_FACTOR Authenticate Existing Factor

The applicant authenticates with his/her exisiting existing factor(s). Username Username/password login is typically the first existing factor that is readily available.

This action may be used for multiple purposes:

Perform authentication with the existing factor(s) to prove knowlegdeknowledge/possession of the respective factor(s).

This action may also be used for checking the applicants eligiblity eligibility (see C_CHECK_ELIGIBLITYELIGIBILITY) based on the credentials used (e.g. email address compared with by searching for a name or e-mail address in a LDAP directory) or the attributes (e.g. affilitationaffiliation) which are send in the authentication response.

Input: Credentials (e.g. username/password combination, certificate)

...

In order to request an additional factor, the applicant provides user applicant information.

There are multiple options to realize this subactivity, e.g.: using federated login, e-mail, showing up at an a registration desk, etc.

Input: user information (e.g. name, affiliation)

...

The applicant selects the type of the new factor to be introduced , if there are several options. The offered options may depend of 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 phase.

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

Input: List of possible factors

Output: factor selected/assigned and known/(or) in possession/... by the applicant

Input:

Output:

C_USE_NEW_FACTOR Use Introduced Factor

Usage of the introduced factor may serve multiple purposes at different stages.

E.g. Use introduced factor to test functioning, to prove knowledge/possession/inheritance/... or to make sure factors match.

Input:

Output:

C_CHECK_ELIGIBILITY Check Eligibility of Applicant

Check if the applicant is eligible to request an additional factor. For example, if there are some  some policy or contractual restrictions. , is the applicant associated with participating organisation and eligible for the offered delivery of the additional physical factor such as token.?

Done by manual or automated check a directory, federated identity, or examination of a written institutional certificate.

Input: applicant's identifying information

Output:  decision: eligible (yes/no)

I: Application and Initiation

Optional initial Optional initial vetting request registration for an additional authentication factor during which the vetting arrangements are made, if needed

• Request
• Factor selection???
• Code (e.g. QR-Code)
• Appointment

C_USE_EXISTING_FACTOR (optional) DEFINED IN C (optional) DEFINED IN C

Used to provide both information about user identity and initial proof (with presumably weaker assurance) that the applicant is who she claims to be.

C_CHECK_ELIGIBILITY (optional, requiring C_USE_EXISTING_FACTOR) DEFINED IN C

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

I_REQUEST_FACTOR (I_REQUEST Factor Request)

The applicant must also provide the delivery address and perhaps even pay for the factor, handling and delivery serviceservice. This may be even as simple as redirection to the external factor provider.

I_FACTOR_DELIVERY

Optional sending 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  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 is can be done during the vetting phase.

I_ARRANGE_VETTING

Optional detailing of vetting, if the . The e-mail, initiation application or other channel is used to communicate a code, appointment details or other relevant information. Includes several steps such as:

• Creation of the (secret) code to be used a the start of vetting to identify the registered vetting request or the new factor used during initiation C_USE_NEW_FACTOR.
• 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 provided upon the previously performed login with the existing factor.

V: Identity Proofing and Information Verification

Do the actual vetting by proofing the applicant's identity and verifying identity information.

• Proof
• Liveness
• Source
• Record
  • 2 different records (on identity, on the new factor)
    

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 deskdesk 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 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 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 softer start of vetting than to immediately demand V_PRESENT_PROOF.

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_VERIFY_IDENTITY in order to allow parallelism at the service desk; should be undo-able if V_VERIFY_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 is quite unlikely but may offer some flexibility by modifying the original choice made during the initiation.

V_HAND_OVER_FACTOR

optional, if the factor such as token is provided by the service desk

• 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

The applicant presents 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 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, 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 - 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

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.?record handover?

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 user applicant or system with userthe applicant's identity proof and the actual 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.

(Optional) V_SOURCE

Check user's identity proof proof (e.g. national ID document, employee ID card) against its original source 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

• Perform Liveness Check V_CHECK_LIVENESS optional, in case online identity vetting, otherwise implied by V_VET_ PROOF conducted with the user.

...

Example2: Upload ID document and real-time recorded selfie.

Input: any mean to means that show liveness

• V_RECORD_PROOF_AUDIT_DATA Record Identity Proof

optionalOptional, 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

Making sure that the applicant possesses the new factor and is able u to use the new factorit. 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 and  or with prior or implied by a record on V_HAND_OVER_FACTOR, but it is better to

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.

. 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: Factor Binding and Activation

Establishment of an operational link between the digital identity of the user and factor.

• Digital ID
• Activation
• Confirmation

(Optional) C_SELECT_FACTOR F_SELECTION DEFINED AT: F

Selection of a particular factor/authenticator may take place while or after identity vetting.

Besides the selection by the user applicant, an assignment of a factor/authenticator e.g. by the registration desk is possible, too.

Input: List of possible factors/authenticators

Output: factor selected/assigned and known/in possession/... by the user

B_DIGITAL_DIGITALID ID Bind factor to digital ID

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

This action is triggered by the registration authority.

Input: verified user identity, digital ID of user, factor

...

In case the factor activation was successful the user , the applicant can now authenticate using more than one factor.

...

Input: result of factor activation (positive/negative)

Output: message to userthe applicant

------------------------------------------------------ Template for providing example realization options ---------------------------------------------------------------------

...