TrustPlatform Identity Management
The TrustPlatform is a biometric identity management system. This stores the identity verified by the Digital Identity Service and performs additional 1:n face identification in the biometric database. This way it creates a new trust factor Uniqueness that prevents the same person to enroll with two different identities.
The structure of a solution integrating TrustPlatform is as follows:
Features of the TrustPlatform
- Biometric database
- 1:n biometric identification (face matching)
- UI for back office operator to review the enrolled identities and to resolve dubious cases
- Trust factor thresholds configuration
- Integration API
Stored Data
The identity data of the onboarded persons are stored in database records called applicant in the TrustPlatform. The contents of this data depend on what was processed by Digital Identity Service (DIS). It can contain following:
- selfie image, images used for liveness check
- images of the ID document
- personal data extracted from the ID document, related to the person and to the document
- evaluation of the identity verification, individual trust factors evaluated for the person
- list of the duplicate records of the same person in the database
API Interface
In addition to the DIS API that needs to be used for remote identity verification, there is ABIS API to handle the applicant records. This API is exposed by the TrustPlatform on its URL. The API reference is published with our demo instance, but it is published also by each instance of TrustPlatform.
Applicant Operations and Use Cases
The TrustPlatform supports following operations:
- Enroll - This is storing the person’s identity (verified by DIS) into a new record
- Update - This updates the record in case of a new ID document issued to the person
- Get - Get data and details from the applicant record
- Verify - Compare the face of a verified person against a record in the database
- Change state - Move the applicant record to a different state
- Anonymize and delete - Deletes the personal data
1. Enroll
TrustPlatform offers two options to store either the unique identity of persons (i.e. individuals) or to store every identity verification attempt. The integration should reflect this choice by using the TrustPlatform differently.
In order to store an identity to TrustPlatform, it has to pass the Trust Evaluation by Digital Identity Service (DIS) first. This processes the face and document images (OCR, face matching, liveness check) in its cache to create a customer object and evaluates its trust factors.
The processed personal data from the customer object are then enrolled from the DIS cache into a database record called applicant in the TrustPlatform by using the DIS API POST /api/v1/customers/{id}/store. At first is the record created in the Incomplete state to perform 1:n identification against all the applicant records in the database that are included in the matcher. This searches all the records with a matching face and returns a list of duplicates. A new trust factor called Uniqueness is created that represents the reciprocal match score to the most similar applicant record.
In order to create a 1:1 pairing of the applicant record in TrustPlatform with a database record of the person in the main solution database, there is a field external ID in TrustPlatform to create the relation. This external ID can be set in the API call during the enrollment. If not set, it is automatically generated from the UUID of the customer object in DIS.
When enrolling an applicant from the DIS to TrustPlatform with DIS API call /store with a flag FINISHED, an applicant is created in one of the states Accepted, In review or Rejected. If storing of abandoned identity verifications is needed, using the flag IN_PROGRESS stores the applicant in the Incomplete state.
The workflow of adding a new applicant record to TrustPlatform is following:
States of the Identity Record
An applicant record can be in one of the following states:
- Incomplete - used to store records temporarily or to store verification sessions abandoned by user (may be represented in UI as Enrolled)
- Accepted - applicant’s identity is verified and trusted (may be represented in UI as Master)
- In review - the applicant’s trust factors are in the range, where additional decision by a human operator is needed
- Rejected - the applicant’s is not trusted as its trust factors are below the threshold (may be represented in UI as Declined)
- Deleted - identities that are no longer needed, with personal data anonymized in compliance with GDPR
Workflow of the States
Using the Uniqueness in Different Scenarios
The uniqueness trust factor is crucial for defining how to handle duplicate records of the same person.
- If the project needs to store as an applicant record in the Accepted state only the persons (= individuals), then the uniqueness should reject all the subsequent enrolls of the same person.
- If the project needs to store every verification attempt without rejecting it because of duplicity, the uniqueness should be suppressed and the solution should have a different database table that would keep a track of what record is an identity verification attempt and what record corresponds to a person (individual).
To avoid rejecting an applicant record because of uniqueness, its trust factor threshold for “Reject if under” should be set to 0. Another option is to store the applicant with the flag IN_PROGRESS, in this case however the Accepted/Rejected state is not set at all and the results of the trust evaluation need to be obtained from the DIS.
2. Update the Applicant Record
It might happen that the applicant’s record needs to be updated, like in case of a new ID document or in case a better selfie photo was captured.
Archiving the Previous Record
The person needs to pass new identity verification in DIS in this case. Before enrolling the new customer object to TrustPlatform, it is necessary to first archive the previous record by removing it from the matcher. This avoids rejecting the new enrollment based on uniqueness. The archiving is done with the ABIS API call POST /abis/v3/applicants/{externalId}/delete. There can be no relation created between the new and the archived record, this needs to be kept at the side of the integrating database.
3. Get the Applicant Record
To get the whole applicant record, the ABIS API call GET /abis/v3/onboarding/applicants/{externalId}/ is used. To get just the selfie face of the applicant record is the call GET /abis/v3/onboarding/applicants/{externalId}/selfies/{selfieIndex}/image.
4. Verifying the Identity of a Person
It is possible to verify if the person using an application is the same as in the applicant record by comparing their face. It is needed to capture the face of that person - this is called a probe face. The liveness needs to be evaluated to avoid fraud and then it needs to be compared to the reference face from an applicant record with corresponding external ID. There are three ways to perform this:
Stateless Verification
In this case the reference face is retrieved from the applicant record using the GET /abis/v3/onboarding/applicants/{externalId}/selfies/{selfieIndex}/image call and compared with the probe face using DIS faces API.
Stateful Verification
The probe face is submitted to the ABIS API call POST /abis/v3/applicants/{externalId}/verify/images, where external ID defines the record from which the reference face is used.
Full Stateful Verification
In this case remains a record tracking the verification - the probe face remains as a new applicant record in the TrustPlatform. If the customer object in DIS is created without a photo of a document, the applicant record created from it is stored in the incomplete state, meaning it will not be used in the face matcher for Uniqueness trust factor of subsequent enrollments. If the document needs to be verified as well, use the IN_PROGRESS flag in the /store API call to have this applicant record in Incomplete state.
In this case a probe record is compared with a reference record using the ABIS API call POST /abis/v3/applicants/{externalId}/verify/references, where the external ID defines the reference applicant record.
5. Changing State of an Applicant
Manual State Changes in TrustPlatform UI
Back office operators can resolve applicants in the state In review, by moving them into either Accepted or Rejected state. He can also delete applicants in any state. When deleting, the personal data is anonymized, and the record stays in the Deleted state.
Changing the States with API
It is possible to change between the states In review, Accepted and Rejected. This change will not affect the result of the trust factors.
The ABIS API call PUT /abis/v3/applicants/{externalId}/move-to-gallery/{galleryName} will change the state of the record defined by external ID.
6. Anonymize and Delete
The compliance with GDPR for removal of personally identifiable data is achieved by anonymizing the record before its soft deletion. All the personal data such as face, liveness and document photos, and the text data are erased, leaving only the results of the trust factors. The record is soft deleted and removed from the face matcher.
There is an ABIS API call POST /abis/v3/applicants/{externalId}/anonymize to delete an applicant record.
If there are multiple records of the same person, all of them should be deleted.