...
- 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 → do we need a "record"-activity for the binding/activation process? → At several points and places for sure.
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
#short descriptionThe actions listed here are common actions which may be used at multiple times at different stages and for various purposes. These actions are:
- Use Exiting Factor
- Select New Factor
- Use Introduced Factor
- Eligibility check
...
Output: Authentication successful (yes/no), attributes is needed (e.g. affiliation)
-??
In order to request an additional factor, the applicant provides applicant information.
There are multiple options to realize this subactivity, e.g.: using federated login, e-mail, showing up at a registration desk, etc.
Input: user information (e.g. name, affiliation)
Output: factor request
-??
C_SELECT_NEW_FACTOR
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 vetting the user was directed to at the initiation phase.
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. Yubikey, Google Authenticator).
...
Output: factor selected/assigned and known / (or) in possession/... by the applicant
Input:
Output:
C_USE_NEW_FACTOR Use Introduced Factor
...
E.g. Use introduced factor to test functioning, to prove knowledge/possession/inheritance/... or to make sure factors match.
Input: new factor
Output: usage of factor took place (for various purposes)
C_CHECK_ELIGIBILITY Check Eligibility of Applicant
Check if the applicant is eligible to request an additional factor. For example, if there are some policy or contractual restrictions, is . Is the applicant associated with participating organisation and eligible for the offered delivery of the additional physical factor such as token?
...
I: Application and Initiation
Optional initial vetting Initial request registration for an additional authentication factor during which the vetting arrangements are made, if needed. Optional actions in case face-to-face vetting will take place. If needed:
- Merge REQUEST_FACTOR and FACTOR_DELIVERY?
- Arrange Vetting
- Request
- Code (e.g. QR-Code)
- Appointment
C_USE_EXISTING_FACTOR (optional) DEFINED IN C
Optional. Used to provide both information about user identity and initial proof (with presumably weaker assurance) that the applicant is who she (s)he claims to be.
C_CHECK_ELIGIBILITY (optional, requiring C_USE_EXISTING_FACTOR) DEFINED IN C
Optional. Used to check whether the applicant is entitled to request the additional factor at the moment of application, as this may incur some costs or use of resources.
C_SELECT_NEW_FACTOR (optional) DEFINED IN C
Optional, if there are several options for factors that may be offered at the start. May affect the options to be used during the vetting phase.
I_REQUEST_FACTOR
Optional. The applicant must may also provide the a delivery address and perhaps even pay for the factor, handling and delivery service. This may be even as simple as redirection to the external factor provider.
I_FACTOR_DELIVERY
Optional sending of the physical factor (typically a token), if such is used, and if this is a part of the provided service.
C_USE_NEW_FACTOR DEFINED IN C
Optional factor (token) preregistration and binding with the request, if . If the applicant is expected to possess a token at the time of registration; alternatively, this can be done during the vetting phase.
I_ARRANGE_VETTING
Optional detailing of vetting. The eE-mail, initiation application or other channel is used to communicate a code, appointment details or other relevant information. Includes May include several steps:
- Creation of the a (secret) code to be used a at the start of vetting procedure to identify the vetting request or the new factor used during initiation (C_USE_NEW_FACTOR).
- If e-mail is used for vetting arrangement, get applicant's e-mail address (e.g. 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 provided upon the previously performed login with the existing factor.
V: Identity Proofing and Information Verification
...