...
This action may also be used for checking the applicants applicant's eligibility (see C_CHECK_ELIGIBILITY) based on the credentials used (e.g. by searching for a name or e-mail address in a an LDAP directory) or the attributes (e.g. affiliation) which are send sent in the authentication response.
...
Output: factor selected/assigned and known (by the applicant or ) in her possession/... by the applicant
C_USE_NEW_FACTOR Use Introduced Factor
...
I: Application and Initiation
Initial The initial request for an additional authentication factor during which vetting 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 are are I_FACTOR_DELIVERY and I_ARRANGE_VETTING. Is In some cases, this phase may be initiated by the Applicant's organisation, not directly by the applicant itself.
...
C_SELECT_NEW_FACTOR (optional) DEFINED IN C !!do we need something here
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_SUPPLY_FACTOR (optional) !!do we need something here
Optional. The applicant may either use his/her own factor, get a factor assigned or buy a factor (token) from the external provider. In the latter case, the applicant may also provide the payment information and delivery address. This may even be as as simple as 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 could be performed (unless C_USE_NEW_FACTOR is required before it). Otherwise ti , it may involve initialisation of the authenticator application or whatever is is required to do so that it could be used during the rest of the scenario.
Input: already collected data useful in arranging the supply, as the applicant name or selected factor
Output: latest delivery date, optional deliverer and, ultimately, actual delivered factor
C_USE_NEW_FACTOR (optional) DEFINED IN C !!do we need something here
...
I_ARRANGE_VETTING (optional) !!do we need something here
Optional detailing of vetting between the applicatn applicant and verifier. E-mail, initiation application or other channel is used to communicate a code, appointment details or other relevant information. May include several steps:
- Creation of a (secret) code to be used at the start of the 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 code in text or QR, email validation link, instructions, vetting application link, service desk contacts, address and appointment details, and whatever else is needed.
- Optional e-mail validation, if e-mail is required for further interactioninteraction, 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 (C_USE_EXISTING_FACTOR).
Input: information about the applicant factor type and factor instance (if it was available and used) or planned delivery, and applicant preferences/choice for the proofing and verification phase
Output: appointment, code, confirmation data and instructions for the applicant, database record on the appointment
V: Identity Proofing and Information Information Verification
Do the actual vetting by proofing the applicant's identity and verifying (or vetting) identity information. This may be perfomed performed by an outside organisation or a separate internal service.
...
V_COMMENCE Begin Vetting, possibly by accessing and validating the prior request !!too long?
Set up the context for identity proofing and information verification by linking prior initiation or performing it if has not been done. Verify, resume, and potentially update the context established during the initiation, or do the key work that that is in it. For example, if the applicant is allowed to come to a service desk without prior registration, C_CHECKCHECK_ELIGIBILITY that is normally done during initiation still must be performed; this may be even necessary if some time has passes passed since the initiation. Other initiation elements related to scheduling of the appointment or linking of initiation and vetting, such as (secret) code creation are pointless, as the applicant is already present and available for vetting.
- Vetting may be rejected and applicant turned back back if the applicant is not eligible (any more) or if the queue is too long or the necessary resources, staff or involved key services are not available at this point.
- Restoring of the information and context established during initiation may include C_USE_EXISTING_FACTOR or use of previously created code to identify the vetting request or the factor used during initiation.
- If the validity of the e-mail address is considered significant, a code or link may be used to make sure that the applicant's e-mail is valid and can be accessed by her.
- This setting up of the context of the applicant's request may be done by restoring it after the applicant, service or desk operator uses the code issued during the initiation. The code that links the applicant with the original application is particularly useful when the applicant does not possess or know the first factor (which may require V_CREATE_DIGITAL_IDENTITY) and is not able to perform C_USE_EXISTING_FACTOR.
- If some time has passed since initiation, it may be necessary to perform C_CHECK_ELIGIBILITY again, as the applicant situation with her organisation may have changed in the meantime. This check could be done based on performed C_USE_EXISTING_FACTOR or the verbally provided identifying information, which, in the case of human-to-human interaction may be a softer start of vetting than to immediately demand V_PRESENT_PROOF.
Input: information about the appointment (link or code)
Output: established or retrieved information about the applicant, appointment and factor, or rejection of further actions.
V_CREATE_DIGITAL_IDENTITY (optional) !!do we need something here
Only if the applicant does not already possess the IdP identity (weak or 1st factor identity). This is optional and often prohibited or discouraged and avoided except for those in need of assistance or VIP individuals. Usually done before Vbefore V_CHECK_PROOF in order to allow parallelism at the service desk; should be undo-able if any of checks before V_PREREGISTER_FACTORfail. 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.
This action should be invalidated if any of the following enrollment actions fails during both vetting and binding phases.
Input: applicant data needed for the the IdP
Output: digital identity created with the IdP, possibly with a flag relation and against misuse if the checks fail, the applicant is able to use it during the rest of the process
V_PRESENT_PROOF !!do we need something here
...
V_HAND_OVER_FACTOR !!do we need something here
Optional, if the factor such as token is immediately provided, e.g. by the service desk. Like Like I_FACTOR_DELIVERY, it can also include an immediate monetary transaction. Recording 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.
Input: available factor, potentially money covering the costs
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.
Read and inspect the ID doc, compare the name with the vetting request, check ID security features, optionally electronically read the ID doc, compare photo/biometrics match with the person.
For online mechanisms, a separate liveness check may be needed to match with the real-world person.
V_EXTERNAL_CHECK (optional) Check External Validity
Check user's identity proof (e.g. national ID document, employee ID card) against its original source (such as issuing authority) or an official register for validity.
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
V_CHECK_LIVENESS (optional) Perform Liveness Check
...
V_RECORD_CHECKS (optional) Record Identity Proof
Optional record for audit purposes is produced, typically for example, by recording the last 6 digits of ID doc number (avoid recording the number of the presented national ID document, but may also include other evidence on performed checks. However, the verifier should avoid the recording of excess personal data, including photos of the person or ID doc)
For accountability purposes (parts of) the identity proof (e.g. last 6 digits of national ID document) is recorded.
document.
InputInput: identity proof
Output: record
...
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 This step should be performed by the applicant and therefore may take require some time time to be performed, so 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 if C_USE_NEW_FACTOR was done during initiation.
This may be required if it also includes personalisation of the factor.
V_CONCLUDE !!do we need something here
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 to saved at his point. Since the different entities/providers may be responsible for verification and binding, and the verifier is typically engaged by the the entity responsible for the long-term identity and credential management (IdP), the verifier should notify it or submit will do it through a notification or by submitting the corresponding entry/record into its 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 userapplicant, confirmation of verified user identity, factor information
...
- Binding of factor and ID
- Activation
- Confirmation
B_FACTOR_AND_ID Bind Factor to Digital ID
Create a long-term binding between the introduced factor and the digital ID of the user based on verified user identity.
Input: digital ID of userapplicant, confirmation of verified user identity, factor information
...
Activate the binding of the digital ID of the user and the new factor. The new factor may need to be unlocked, enabled or otherwise modified so that it can be used in regular authentications. For example, it may be in a state in which it was personalized personalised and populated with all needed data , but still marked as "not activated", which allows authentications with target services to fail even without contacting the factor issuer or IdP.
...
Output: message to the applicant
Detailed Attributes
...