Started with SURF's "Remote vetting for SURFconext Strong Authentication" descriptions of RV flows.
The content was refactored with What is ITU-T X.1254 and why to use it?/ 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 below descriptions our use own terminology, our slightly shifted terminology, e.g. with factors vs , 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_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
...