You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 52 Next »

1---

V Do the actual vetting by proofing the applicants identity and verifying identity information

V_RESUME ENROLLMENT Verify, resume, and potentially update the context established during the initiation

V_CONFIRM_AVAILABILITY The vetting can be rejected if the service desk operator or front or back-end services are not available

V_USE_VETTING_CODE if it was provided within I_ARRANGE_VETTING, the service or operator check the code that was issued during the initiation and that is now provided by the applicant. this code is used to link the person with the original application, especially the applicant does not possess or know the first factor, or to avoid

C_CHECK_ELIGIBILITY (optional, may require C_USE_EXISTING_FACTOR) Even if it was performed during the initiation, the applicant situation may change in the meantime; may depend on prior C_USE_EXISTING_FACTOR or V_PRESENT_PROOF, or on the identifying information verbally provided by the applicant (this is more humane than starting with V_PRESENT_PROOF right awaya).

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_VET_APPLICANT_IDENTITY in order to allow parallelism at the service desk; should be undo-able if V_VET_APPLICANT_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 providng the applicant with them)

C_SELECT_FACTOR defined at C quite unlikely but may offer some flexibility by modifying the original choice made during the initiation

V_HAND_OVER_FACTOR optional (if the token is provided by the service desk)

V_APPLICANT_IDENTITY detailed check of ID validity and match with the 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,

V_CHECK_LIVENESS optional, in case online identity vetting, otherwise implied by V_VET_ PROOF conducted with the user

V_RECORD_PROOF_AUDIT_DATA optional, typically by recording the last digits of ID doc number (avoid recording excess personal data, photos of the person or ID doc)

V_USE_TOKEN if HAND_OVER_TOKEN, done by the user in parallel with V_VET_APPLICANT_IDENTITY

V_PASSWORD_AUTHENTICATION like U_PASSWORD_AUTHENTICATION

V_REGISTER_TOKEN like U_INTRODUCE_FACTOR could be standalone even without V_HAND_OVER_TOKEN, but unnecessary with U_INTRODUCE_FACTOR/U_PREREGISTER_TOKEN and V_USE_VETTING_CODE; the used token will be later bound to digital identity

V_RECORD if both V_VET_APPLICANT_IDENTITY and V_USE_TOKEN if HAND_OVER_TOKEN were successful, otherwise reverse V_CREATE_DIGITAL_IDENTITY

B  I would move F_SELECTION DEFINED and F_AUTHENTICATION earlier

2---------------------------

new Structure based on yesterdays discussion:

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

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 some of ITU-T X.1254 entity authentication assurance framework processes. The following processes from its "8.1 Enrolment 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 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

The used names and descriptions aim to be mapable 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 on authentication factors (something 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

C_USE_EXISTING_FACTOR Authenticate Existing Factor → TODO:  C_LOGIN?

The applicant authenticates with his/her exisiting factor(s). 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 knowlegde/possession of the respective factor(s).

This action may also be used for checking the applicants eligiblity (see C_CHECK_ELIGIBLITY) based on the credentials used (e.g. email address compared with LDAP directory) or the attributes (e.g. affilitation) which are send in the authentication response.

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

Output: Authentication successful (yes/no), attributes is needed (e.g. affiliation)

-??

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

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

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

Output: factor request

-??

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

C_SELECT_FACTOR

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

Input: List of possible factors/authenticators

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

Input:

Output:

I: Application and Initiation

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

  • Note: * is used as a wildcard. Set the appropriate value which applies to the specific action.
  • 1F: may be used to indicate that a specific action refers to the first factor
  • 2F: may be used to indicate that a specific action refers to the second factor

C_USE_EXISTING_FACTOR (optional) DEFINED IN C

C_CHECK_ELIGIBILITY (optional, requiring C_AUTHN)  DEFINED IN C

C_SELECT_FACTOR DEFINED IN C

Optional, if there are several options for factors that may ve offeret at he 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 service.

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, if the applicant is expected to possess a token at the time of registration; alternatively, this is done during the vetting.

I_ARRANGE_VETTING

Optional detailing of vetting, if the e-mail, initiation application or other channel is used for to communicate the 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 while using the factor during during.
  • 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 upon the previously performed login with the existing factor.

V: Identity Proofing and Information Verification

Capture and verify information about a user for identification.

(Optional) V_SCHEDULE Identification session arrangement and scheduling

Schedule an identification session in order to identify the user.

Optional action. Real-time interaction may not be required.

Input:

Output: identity vetting appointment

Effect on LoA: not applicable

V_PROOF???

Compare the claimed identity (information) which is transmitted by the user or system with user's identity proof (e.g. ID doc, activation code).

Input:

Output: 

Effect on LoA:

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

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 mean to show liveness

Output: 

Effect on LoA: ???

(Optional) V_SOURCE

Check user's identity 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

V_RECORD Record Identity Proof

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

B: Factor Binding and Activation

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

(Optional) 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 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_DIGITALID Bind factor to digital ID

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

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

Output: binding between digital ID and factor

B_ACTIVATE Activate Binding of Digital ID and New Factor

Activate the binding of the digital ID of the user and the new factor.

This action is triggered by the registration authority.

Input: binding between digital ID and factor

Output: decision: activation successful/unsuccessful

B_CONFIRMATION Inform User about Factor Activation

Inform the user about the correct or incorrect activation of the factor.

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

This action is triggered by the registration authority.

Input: result of factor activation (positive/negative)

Output: message to user


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

could consider more attributes such as:

Likely to be mandatory in MFA: (yes/no)
Risks if omitted: (mostly security-related)
Effect on level of assurance: (how it increases, decreases LoA)

+
Other potential technical concerns/issues
Potential organisational (IP, NREN, GEANT) concerns/issues
Potential end-user concerns/issues

Example realization options

 

Federated Login

Short description

Federated login is used to provide user information

Input

User information (e.g. name, email, organization) typically via a SAML assertion

Output

Factor request

Advantages


Drawbacks/Risks






ActivitySubactivitySubsubactivity

Mapping

I (Identity/Identification)

F (Factor) → 1F if first factor, 2F if second factor

Mandatory/optional?

(typically)

Input

(typically)

Output

(typically)

(Security) risks if omitted

(general)

Dependencies

(could be quite specific)

Increases/Decreases LoA

(general)

FRq 1) 2FA token request

1.0) Should we have a first factor authentication subactivity here as a gatekeeper for "User provides user info"

FRq.UI 1.1) User provides user info


F_request

(e.g. 2F_request if second factor is requested)

mandatoryuser information (e.g. name, email, organization, e.g. via SAML assertion)token request
  • First check to be entitled to register 2FA token (e.g. federated login, email address is present which is associated with user/org. LDAP)
Eligibility either needs to be checked in 1.1 or 3.1N/A
FReg 2) 2FA (pre-)registrationFReg.Sel 2.1) User selects factor
N/A, see F_selectoptional





FReg.Authc 2.2) User performs authentication with that factor for binding and to prove possession/knowledge/...


N/A, see F_authenticate
optional




Ident 3) Identification
(eligibility check;identity vetting using ID doc or alternative identity assertion method;unsure match of the person and her digital identity)

Ident.Sched 3.0) Identification session arrangement and scheduling (!optional)



I_schedule








Ident.ElegC 3.1) Check eligiblity of user & possession of first factor

I_checkEligibility

1F_authenticate

optional if already performed in 1.1





Ident.UVet 3.3) Vet identity of user











Ident.UVet.CkClm 3.3.1) Compare claimed/transmitted/spoken information with user's identity proof (e.g. ID doc, activation code)I_vet_????mandatory






Ident.UVet.ULive 3.3.2) Perform Liveness Check

(e.g. ID doc photo vs. real life face/ selfie)

I_vet_liveness







Ident.UVet.IDVal 3.3.3) Check user's identity proof with its original source for validityI_vet_originalSourceoptional





Ident.UVet.Rec 3.3.4) Record identity proof (par of ID doc, or just note success???)I_record





FBind 4) Token bindingFBind.Poss 4.1) User chooses own token or handover of token to user (possession)
F_selectoptional when activity 2 took place





FBind.DigID 4.2) Bind factor to digital ID


F_bind

mandatory,

may already be performed in step 2

precondition: successful 3.2.1)







FBind.FPoss 4.3) Token-proof of-possession (e.g. test authentication)
2F_authenticateoptional





FBind.FAct4.4) Factor activation & record

F_activate

F_record

mandatory

precondition: successful 3.2.1







FBind.FAck 4.5) Inform user about factor activation
F_confirmActivation








2FA token request2FA token (pre-)registration
IdentificationToken binding

1.1) User provides user info2.1) User selects 2FA token2.2) User performs authentication with that token to prove possession3.1) Eligibility check of user3.2) Vet identity of user4.1) User chooses own token or handover of token to user4.2) Bind token to digital ID4.3) Token-proof-of-possession4.4) Token activation & record4.5)Inform user





3.2.1) Compare claimed/transmitted/spoken information with user's identity proof3.2.2) Check user's identity proof with its original source for validity3.2.3) Record identity proof




Method
Live video

(tick)

federated login

(tick)(error)

(error)

(checked in 1.1 via login)









...
























  • No labels