Started with SURF's "Remote vetting for SURFconext Strong Authentication" descriptions of RV flows.
The content was refactored with INTRO TO ITU-T .1254 flowing text introduction to the ITU thing plus arguments for using itX.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.
These below are now our own terminology
These below is a vocabulary developed by ourselves
Factors vs credentials.
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)Explain CIVB sections, 3 general phases.
Descriptions of actions are process and flow-oriented, not data-oriented. therefor, the descriptions of inputs Inputs and outputs descriptions are therefore rather informal.
C: Common Actions
...
C_USE_EXISTING_FACTOR Authenticate Using Existing Factor (Any alternative phrasing for _EXISTING alternative?)
The applicant authenticates with his/her factor(s) already in place and function in the system. Username/password login is typically the first existing factor that is readily available.
...
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
...