Example Workflows

In this section example workflows of potential business cases are depicted. To this end, sequence diagrams with VCSP API interactions with third party customer systems are included.

Subject voice authentication in call center

This use case describes a scenario where a subject which uses VCSP for the first time to register his/her voice in the system for future uses.

In a call center use case, the call center agent will have to request the data from the user to perform the identity proofing (based on their own means) and to retrieve the voice sample to enroll the user in VSCP.

Step 1: Enroll subject with voice sample

In this sequence diagram it can be seen a possible flow between a user from a call center and the interaction with the agent to enroll his/her voice into VCSP.

As it can be observed, the interaction between customer system and VCSP reduces to an API call to create the enrollment for the corresponding user. Basically in this request must be provided the subject identifier along with the biometric sample and the credential configuration for the generated biometric template. Further information about POST /enrollments operation can be found here.

Step 2: Authenticate user with voice sample

Once the enrollment of a subject in VCSP with identifier 1111 has been completed, the user can make use of the voice authentication the next time that wants to perform some action via the call center. A possible flow is depicted in the diagram below.

The call center agent can retrieve the user identifier within the system and launch an authentication process against VSCP to ensure his/her claimed identity. Once the authentication process ends up successfully, the agent can proceed with the operation trusting that the user identity has been verified. In the diagram, it can be seen that the API call required by the customer to implement is the authentication request to VCSP. This operation is a POST /matchings. In this request, the subject identifier to verify identity is provided along with a biometric sample. The response includes whether there has been a HIT (the biometric score is higher than the provided assurance threshold) or not and information about the sample generated to perform the verification with the stored credential. Further details of this operation can be found here.

Prevent fraud by avoiding registration of blocked users

This use case describes a scenario in which a customer wants to block registration of users in their system belonging to a predefined blocklist. In market sectors such as banking, insurance, etc. avoiding fraud is paramount. Companies may already have identities detected as criminals and therefore they want to keep these individuals away from their systems.

VCSP offers the means to create groups of credentials that can be used for identification processes. Next, it is shown how to articulate this business case.

Step 1: Create blocklist group with face credentials

The first step is to create a group with the target credentials in it. To do that, first it is required to enroll all the faces to the system with an appropriate tag that denotes the blocked characteristic.

VCSP offers an endpoint to enroll users in a batch. The pre-requisites are to have all the face samples (images) from the potential criminals and build a batch file following a defined convention. Once users are enrolled, they can be added to groups. Next, a diagram it is shown that comprises the following steps:

1. Tags creation: Create the tag role:blocklist to be used in enrollment process
2. Batch enrollment of blocklist faces: Enroll faces as credentials in VCSP system. This step is asynchronous, enrollments will be processed in background. The response includes a task_id to monitor the progress of the batch enrollment process.
3. Check batch enrollment status: Monitor the degree of completion of the batch enrollment process.
4. Check batch result: Get the result summary of the batch enrollment.
5. Group creation: Create the group and populate it with the credentials enrolled in the batch process.

The API calls involved in this process between customer and VCSP are the following:

• POST /tags: Create tag role:blocklist to be used in batch enrollment
• POST /enrollments/batch: Enroll blocked users faces as credentials.
• GET /tasks/{task_id}: Get status of a batch enrollment task. Monitor the degree of completion.
• GET /task/{task_id}/result: Get the summary result of a batch enrollment task.
• POST /groups: Create a group with a specific credential configuration. The credential configuration describes the type of credentials that can be added to the group.
• PATCH /groups/{group_name}: Add credentials to an already created group.

Further information of these operations can be found in here.

Note on batch file schema

The batch file must comply with the following convention:

• A folder named samples with the image files in it.

• A file applicants.json with the following schema:

   [
    {
    "sample": "file://samples/john_doe.jpg",
    "applicant": {
        "subject_id": "000001",
        "credential_configuration_urn":  "urn:vcsp:credential_configurations:face_selfie:v1",
        "assurance_method_urn": "urn:vcsp:assurance_methods:enrollment:thresholds:v1",
        "assurance": {
            "authenticity_threshold": 0.8
        },
        "tags": ["role:blocklist"]
        }
    },
   {
   "sample": "file://samples/jane_doe.jpg",
   "applicant": {
        "subject_id": "000002",
        "credential_configuration_urn": "urn:vcsp:credential_configurations:face_selfie:v1",
        "assurance_method_urn": "urn:vcsp:assurance_methods:enrollment:thresholds:v1",
        "assurance": {
            "authenticity_threshold": 0.8
        },
        "tags": ["role:blocklist"]
        }
    }
    ]
  

Each entry corresponds to an enrollment process. It must be noted that each enrollment is independent so as it is possible to enroll multiple credentials with different configurations in the same operation.

Step 2: Identification of a blocklist individual

Once credentials from those individuals are labeled as blocked by the customer and group together, it is possible to detect if one of those subjects intends to register in the customer system. Customers just need to integrate an extra check within their onboarding process to confirm that the potential user identity does not belong to the blocked group. In addition, they can make use of the fraudulent users' detection to take further measures in this regard.

Next, a flow diagram is shown wherein a blocked user tries to use customer services.

As it can be seen, with one call to VCSP service, the customer can detect whether the potential user is one of the individuals inside the blocked group and take some actions as a consequence. In the example, the registration is denied (excluding the reason) and an agent is informed about the registration attempt of a blocked user.

The API call involved in this process is POST /matchings wherein the claimant it is a group. For more information about the endpoint interface go here.