1--- Structure based on Flow: SURFnet 4.8-9 Registration Desk (Self-service token registration) and Flow: SURFnet 4.4 Mobile Application with Optical Scan + NFC +Selfie, to be combined with Jule's detailed structure below...
V Do the actual vetting by proofing the applicants identity and verifying identity information
V_CONFIRM_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 optional, 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. Includes 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 check of their alignment with the enforced policies, 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
...
- Authenticate Exiting Factor
- Use Introduced 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?
...
- Proof
- Liveness
- Source
- Record
- 2 different records
B Credential Factor Binding and Issuance? (if Enrollment or Issuance are overloaded by the existing frameworks or often used with different meaning)
Activation
- Digital IDDigitalID
- Activation
- Confirmation
3 -------------------------------
C: Commons
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.1.1 Credential pre-processing
- 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_AUTHNUSE_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 readibly 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)
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
-??Output: Authentication successful (yes/no), attributes is needed (e.g. affiliation)
C_USE_NEW_FACTOR Use Introduced Factor
...
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 factor2F: may be used to indicate that a specific action refers to the second factor
C_AUTHN (optional) DEFINED IN C
...
to
...
the specific action.1F: may be used to indicate that a specific action refers to the first factor2F: may be used to indicate that a specific action refers to the second factor
C_USE_EXISTING_FACTOR (optional) DEFINED IN C
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)
...
C_CHECK_ELIGIBILITY (optional, requiring C_AUTHN) DEFINED IN C
...
- 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.
...
Effect on LoA: not applicable
B:
...
Factor Binding and Activation
Establishment of a binding an operational link between the digital identity of the user and factor
...
...