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 authenticatedare referred to as applicants, who are the physical persons whose identity is to be authenticated.
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: C
...
ommon 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)
...
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
...