Started with SURF's "Remote vetting for SURFconext Strong Authentication" descriptions of RV flows.
The content was refactored with ITU-T X.1254/ ISO/IEC 29115 recommendation "Entity authentication assurance framework" as a conceptual basis. Publicly available and influential.
The following generalised functional units (actions) serve to design and implement the vetting scenarios for second factor and multifactor authentication that 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
...
Of all processes described in "8.2 Credential management phase" - only these some are addressed here, as they are related with initialisation and issuance of the authentication factors, which, in our scenarios, are closely tied to identity proofing and verification:
...
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 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.
C: Commons
The below descriptions our use our slightly shifted terminology, e.g. with factors, not credentials.
Actions are grouped in four sections: Common Actions, three general phases (Initiation, Verification, Binding).
Descriptions of actions are process and flow-oriented, not data-oriented. Inputs and outputs descriptions are therefore rather informal.
C: Common Actions
The actions The actions listed here are common actions which may be used at multiple times at different stages and for various purposes.
C_USE_EXISTING_FACTOR Authenticate Using Existing Factor (Any alternative phrasing for _EXISTING?)
The applicant authenticates with his/her existing factor(s)) already in place and function in the system. Username/password login is typically the first existing factor that is readily available.
...
Input: Credentials (e.g. username/password combination, certificate) provided by the user
Output: Authentication successful (yes/no), attributes is needed (e.g. affiliation)
C_SELECT_NEW_FACTOR Select Type of Factor That to be Introduced
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.
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. YubikeyYubiKey, Google Authenticator).
Input: List of possible factors provided by the user
Output: factor selected/assigned and known by the applicant or in her possession of the applicant
C_USE_NEW_FACTOR Use Introduced Factor
...
The 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 The dedicated actions in this phase are are I_SUPPLY_FACTOR _DELIVERY and I_ARRANGE_VETTINGVERIFICATION. In some cases, this phase may be initiated by the Applicant's organisation, not directly by the applicant itselfby the Applicant's organisation, not directly by the applicant itself.
Some actions from the Commons block are referenced here to give an example how Application and Initiation phase may take place in practice. They are marked as optional actions.
C_USE_EXISTING_FACTOR (optional) DEFINED IN C
...
Optional. The applicant may either use his/her own factor, get a factor assigned or buy a factor (token) from the an external provider. In the latter case, the applicant may also provide the payment information and delivery address. This may even be as simple as a mere redirection to an external supplier.
If needed, this includes physical sending of the factor (typically a token) and delivery period warranty so that I_ARRANGE_VETTING VERIFICATION could be performed (unless C_USE_NEW_FACTOR is required before it). Otherwise, it may involve initialisation of the authenticator application or whatever is required to do so that it could be used during the rest of the scenario.
...
Do the actual vetting by proofing the applicant's identity and verifying (or vetting) identity information. This may be performed by an outside external organisation or a separate internal service.
...
V_CREATE_DIGITAL_IDENTITY (optional) Create Digital Identity (for applicant applicants without first factor)
Only if the applicant does not already possess the IdP identity (weak i.e. identity that can be only attested with the first factor). This is optional and often prohibited or discouraged and avoided except for those in need of assistance or VIP individuals. At a service desk, this is to be done before V_CHECK_PROOF in order to allow parallelism; should be undo-able if any of checks before V_RECORD_CHECKS 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.
...
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) Hand Over Factor (to applicant)
Optional, if the factor such as token is immediately provided, e.g. by the service desk. Like I_SUPPLY_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.
...
Output: factor handover record
V_CHECK_PROOF (Local) Check of the Presented Proof
Detailed (local) check of ID validity and match with the person of the applicant. Compare the claimed identity (information) which is transmitted by the applicant or system with the applicant's identity proof and the actual person.
...
Make sure the identity proof is not expired, revoked or invalid.
Input: user's identity proof
Output: verified identity proof
Effect on LoA: typically higher LoA require this action
...
Example2: Upload ID document and real-time recorded selfie.
Input: any means that show liveness
Output: liveness verified
V_RECORD_CHECKS (optional) Record Identity Proof
...
A record should be made even if some of checks failed. If any of checks verification failed, V_CREATE_DIGITAL_IDENTITY may need to be undone, and the applicant may need be requested to return the token provided in V_HAND_OVER_FACTOR or even I_SUPPLY_FACTOR.
Input: identity proof
Output: record
Effect on LoA: not applicable
C_USE_NEW_FACTOR (optional) DEFINED IN C
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 new token will be bound to the applicant's digital identity. This step should be performed by the applicant and therefore may require some time to complete, and thus it 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 omitted if C_USE_NEW_FACTOR was done during initiation.
...
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 at his this point. Since the different entities/providers may be responsible for verification and binding, and the verifier is typically engaged by the entity responsible for the long-term identity and credential management (IdP), the verifier will do it through a notification or by submitting the corresponding entry/record into the IdP 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 applicant, confirmation of verified identity, factor informationEffect on LoA: not applicable
B: Factor Binding and Activation
...