Liveness detection 

This document describes how to use the IDEMIA Identity and Verification (ID&V) API for verifying an individual’s face portrait, both for liveness detection and user verification against a reference identity evidence.

Biometric services 

ID&V offers a service for capturing and validating a user’s portrait. This service:

• captures the user’s portrait during a video stream.
• verifies that the user is a live person.
• verifies that the portrait corresponds to the portrait that is displayed on a reference identity document (evidence). That reference identity document will have been previously verified by the service.

The best image is extracted from a liveness portrait video capture which can be performed from a browser or from a native operating system environment. This best image will be used internally in ID&V in the same way as a selfie capture image for biometric user verification using the ID&V biometric matching functionality.

Liveness portrait video capture using a web browser 

1. The server initializes the liveness session.
2. Liveness check is performed using the web browser to establish the video stream with the Biometric server.
3. The liveness session data is collected by the server.
4. The server analyzes the liveness session data, takes the decision, and extracts the best portrait image.

Liveness portrait video capture using a native SDK 

The device uses a native SDK which initiates the user's liveness portrait capture. The server side makes the decision.

1. The server initializes the liveness session.
2. Liveness check is performed using the native SDK.
3. The liveness session data is collected by the server.
4. The server analyzes the liveness session data, makes the decision, and extracts the best portrait image.

Requirements 

To execute the scenarios, the client application needs:

• API keys and URLs to access the Identity Proofing service. The GIPS-RS key for back-end to back-end communication. The GIPS-UA key is for the user-facing application to Identity Proofing back-end communication.

• In case of liveness detection by using a web browser: An API key and a URL to establish the video stream between the user-facing application and the Biometric server (BIOSERVER-VIDEO).

• In case of liveness detection by using a native SDK: A URL to access the Identity Proofing service. This defines the liveness check configuration.

Details about the video stream creation with a web browser and the Biometric Server are available in Biometric Services SDK API Guide.

Details about face capture with the native SDK are available:

• for iOS: iOS Biometric Capture SDK

• for Android: Android Biometric Capture SDK

Additionally, the client application must notify the ID&V service that it has obtained the user’s consent for processing their self-portrait image. That step will be explained in the sequence diagrams of this document.

Scenario 

In this scenario, we detail how a client application verifies an identity document and a user’s portrait using a video stream to capture the face, and determine the liveness of the user.

There are two ways for capturing a self-portrait image of an individual with liveness detection:

• Liveness video capture using a web browser

• Liveness video capture using a native SDK

Liveness video capture using a web browser 

Steps overview

1. Create the identity.
2. Submit consent.
3. Submit an identity document capture.
4. Start a liveness video capture by using the browser.
5. Retreive portrait verification results and identity proof.

In the following example, we use a passport as a reference identity document.

Steps

Step 1: Create identity

Create an identity on the Identity Proofing server that will receive all of the data and gather the verification results related to this identity.

Step 2: Submit consent

Notify the Identity Proofing service of the different verifications and permissions the user has consented to.

Step 3: Submit identity document capture

Send the identity document images for verification.

• The service performs the document authentication and extracts the user’s personally identifiable information (PII) and document information;

• If the identity document image is usable:

  • The service performs the biometric coding of the document image to verify the quality of the portrait.

  • The service selects the document’s portrait as the reference portrait for this user.

  • If the identity document is valid, its status becomes VERIFIED and the identity document is assigned a score depending on the number and quality of verifications that have been performed (for example, LEVEL2).

Step 4: Start a liveness video capture through the web browser

Initialize a session with the service to verify a user’s liveness and capture the user’s portrait.

The client application:

• Sends a request to the service to start a live video capture.

  • The service creates a session in BioServer and returns the sessionId to the client application.

• Initializes a peerConnection with BioServer for capturing the video stream.

• Receives a notification from BioServer that the liveness capture is done.

  • The service receives a callback from BioServer that the liveness capture is done.

  • The service retrieves the result of the liveness from BioServer.

  • The service gets the best image extracted from BioServer.

The service performs the face biometric matching between the reference image from the identity document and the best image is extracted from the liveness video capture.

Step 5: Get portrait verification result and retrieve proof

The client application can retrieve the result of the face capture and verification:

• If the portrait images match, the portrait status is VERIFIED and the portrait is assigned a score equal to the score of the document from which the reference image was extracted (if the identity document score is LEVEL2, then the portrait score after successful matching will also be LEVEL2).

• If portrait image does not match the reference document, the portrait status is INVALID and the portrait is assigned a LEVEL0 score and an error code.

The status and score of the identity document do not change.

Once the client application has reached the end of the process, it can close the transaction by retrieving the proof file that contains all of the identity verification details.

Liveness video capture using a native SDK 

Steps overview

1. Create the identity.
2. Submit consent.
3. Start a liveness video capture by using the native SDK.
4. The native SDK starts the liveness metadata collection.
5. Submit an identity document capture.
6. Retreive portrait verification results and retrieve proof.

In the following example, we use a mobile application with a native SDK for the live video capture.

Steps

Step 1: Create identity

Create an identity on the Identity Proofing server that will receive all of the data and gather the verification results related to this identity.

Step 2: Submit consent

Notify the Identity Proofing service of the different verifications and permissions the user has consented to.

Step 3: Start a liveness video capture by using the native SDK

Create a video capture session and initialize the liveness parameters to be used for verifying a user’s liveness by using the native SDK and capture the user’s portrait.

The client application:

• Sends a request to ID&V for starting a live video capture by using the native SDK

The Identity Proofing service:

• Creates a session in BioServer
• Initializes the liveness parameters in BioServer depending on the configuration defined for the client application
• Returns to the client application the liveness session identifier to be used by the SDK to retrieve the liveness parameters and perform the liveness face capture

Step 4: The nativeSDK starts the liveness metadata collection

The client application:

• Retreives the liveness parameters and checks the signature of the BioServer response

• Prepare liveness metadata by submitting to BioServer the encryptedMasterSecret, encryptedDeviceId, livenessDeviceInfo and sdkParameters to get the selfie capture permission.

• Start the selfie video capture of the user

• Send the liveness metadata and video record information to BioServer.

Note: Details about the Replay Liveness APIs are available here: Replay Liveness APIs

The Identity Proofing service:

• Receives a notification from BioServer that the liveness capture is done

• Retrieves the result of the liveness verification from BioServer

• Gets the user's portrait image extracted by BioServer

• Performs the face biometric matching between the reference image from the identity document and the best image is extracted from the liveness video capture.

Step 5: Submit identity document capture

The client application sends the identity document images for verification.

The Identity Proofing service:

• Performs the document authentication and extracts the user’s personally identifiable information (PII) and document information;

• If the identity document image is usable:

  • Performs the biometric coding of the document image to verify the quality of the portrait.

  • Selects the document’s portrait as the reference portrait for this user.

  • If the identity document is valid, it status becomes VERIFIED and the identity document is assigned a score depending on the number and quality of verifications that have been performed (for example, LEVEL2).

• Performs the face biometric matching between the reference image from the identity document and the user's portrait image is extracted from the video capture.

Step 6: Receive portrait verification result and retrieve proof

The client application can retrieve the result of the face capture and verification:

• If the portrait images match, the portrait status is VERIFIED and the portrait is assigned a score equal to the score of the document from which the reference image was extracted (if the identity document score is LEVEL2, then the portrait score after successful matching will also be LEVEL2).

• If portrait image does not match the reference document, the portrait status is INVALID and the portrait is assigned a LEVEL0 score and an error code.

The status and score of the identity document do not change.

Once the client application has reached the end of the process, it can close the transaction by retrieving the proof file that contains all of the identity verification details.

Web Service calls 

There are many ways to implement the appropriate web service requests depending on your programming language. For the sake of clarity, the request examples use the cURL tool syntax.

The variables used in the request URLs are:

Create an Identity 

This request initiates the verification process with ID&V.

The request looks like this:

Shell
1curl -X POST https://[URL_MAIN_PART]/gips/v1/identities  \
2-H 'Content-Type: multipart/form-data' \
3-H 'apikey: [APIKEY_VALUE]'

When this request is sent, the ID&V response contains an id field. The value of that field replaces IDENTITY_ID in subsequent requests.

Sample response:

JSON
1{
2  "id": "gips-c386c92e-fd7a-4024-bb41-b0f2aab7540c",
3  "status": "EXPECTING_INPUT",
4  "levelOfAssurance": "LOA0",
5  "creationDateTime": "2022-12-20T14:46:27.2675744",
6  "evaluationDateTime": "2022-12-20T14:46:27.7473597",
7  "upgradePaths": {}
8}

Submit consent 

Consent is a notification from the client application to ID&V that the user consents to their personal information (in this case, their portrait image) being processed by ID&V for a given period.

With this request, the client application notifies ID&V that the user has consented to the biometric processing of their portrait image.

The request looks like this:

Shell
1curl -X POST \
2  https://[URL_MAIN_PART]/gips/v1/identities/[IDENTITY_ID]/consents \
3  -H 'Content-Type: application/json' \
4  -H 'apikey: [APIKEY_VALUE]' \
5  -d '[{
6    "approved": true,
7    "type": "PORTRAIT"
8}]'

Sample response:

JSON
1[
2  {
3    "consentId": "781c83db-2b6d-462d-8225-3f2d7fe243f9",
4    "approved": true,
5    "type": "PORTRAIT",
6    "validityPeriod": {
7      "from": "2018-01-01",
8      "to": "2023-06-20"
9    }
10  }
11]

Submit a document capture 

With this request, the client application submits an identity document to ID&V for processing. The supported identity document types are:

• Passport

• Identity card

• Driver's license

• Resident card

The request looks like this:

Shell
1curl -X POST \
2https://[URL_MAIN_PART]/gips/v1/identities/[IDENTITY_ID]/id-documents/capture \
3-H 'Content-Type: multipart/form-data' \
4-H 'apikey: [APIKEY_VALUE]' \
5-F 'DocumentFront=@[ABSOLUTE_LOCAL_PATH_TO_IDDOCUMENT_FRONT]'
6-F 'DocumentBack=@[ABSOLUTE_LOCAL_PATH_TO_IDDOCUMENT_BACK]'
7-F 'DocumentCaptureDetails=@[ABSOLUTE_LOCAL_PATH_TO_DOCUMENTCAPTUREDETAILS]'

DocumentCaptureDetails is a JSON file with the following format:

JSON
1{
2  "jurisdiction": "[COUNTRY_CODE]",
3  "documentType": "[DOCUMENT_TYPE]",
4  "source": "[IMAGE_SOURCE]"
5}

Sample response:

JSON
1{
2  "status": "PROCESSING",
3  "type": "PASSPORT",
4  "id": "a5b568e5-25df-4323-b34e-c5405823b706"
5}

Check document status 

With this request, the client application checks the processing status of the submitted identity document.

The request looks like this:

Shell
1curl -X GET \
2https://[URL_MAIN_PART]/gips/v1/identities/[IDENTITY_ID]/status/[IDDOCUMENT_ID] \
3-H 'apikey: [APIKEY_VALUE]'

The client application can use this API to implement polling and proceed to the next steps only when it's certain that the document’s status is VERIFIED, or it will prompt the user to retry with another document capture.

Sample response:

JSON
1{
2  "status": "VERIFIED",
3  "type": "PASSPORT",
4  "id": "a5b568e5-25df-4323-b34e-c5405823b706"
5}

Values for status can be:

• VERIFIED - document or portrait has successfully been verified. When VERIFIED, a document or portrait is scored on a scale of 1 to 4.

  • LEVEL1: low confidence
  • LEVEL2: medium confidence
  • LEVEL3: high confidence
  • LEVEL4: very high confidence

• INVALID - document or portrait is considered invalid after the checks performed

• NOT_VERIFIED - document or portrait was processed, but not enough checks were performed to take a decision, typically due to poor quality of the image, or an unsupported document type

• PROCESSING - evidence is currently being processed by the service

• ADJUDICATION - evidence is currently being reviewed by a human expert

Start a live capture video session using a browser 

With this request, the client application starts a live capture video session of the person to verify the liveness of the user, and extract the user's face image that will be compared with a portrait extracted from a reference evidence such as a VERIFIED identity document's portrait.

The service provides, in response, a BioServer session identifier for initializing the video stream between the browser and the BioServer and then links the result to the rest of the user's identity.

The request looks like this:

Shell
1curl -X POST \
2  https://[URL_MAIN_PART]/gips/v1/identities/[IDENTITY_ID]/attributes/portrait/capture-session?mode=webSDK \
3  -H 'Content-Type: application/json' \
4  -H 'apikey: [APIKEY_VALUE]'

Sample response:

JSON
1{
2  "status": "PROCESSING",
3  "type": "PORTRAIT",
4  "id": "e7917cff-5727-4106-a756-1ddf4216aca6",
5  "sessionId": "0991ced"
6}

Start a live capture video session using a native SDK 

With this request, the client application starts a live capture video session of the person in order to verify the liveness of the user, and extract the user's face image that will be compared with a portrait extracted from a reference evidence (e.g. a VERIFIED identity document's portrait).

The Service will provide, in the response, the liveness parameters (liveness type, security Level, number of challenges to ask, and certificate) that will enable the performance of the liveness and face capture with the native SDK.

The request looks like this:

Shell
1curl -X POST \
2  https://[URL_MAIN_PART]/gips/v1/identities/[IDENTITY_ID]/attributes/portrait/capture-session?mode=nativeSDK \
3  -H 'Content-Type: application/json' \
4  -H 'apikey: [APIKEY_VALUE]' \
5  -d '{
6	"type": "LIVENESS_PASSIVE_VIDEO",
7	"securityLevel": "MEDIUM",
8	"nbChallenge": 2
9}'

The payload of this request is optional and can be empty. In that case, the default configuration is applied.

Description of JSON fields in the payload:

Sample response:

JSON
1{
2  "status": "PROCESSING",
3  "type": "PORTRAIT",
4  "id": "12971f18-16ce-4a10-890a-bda5ffc7ecd7",
5  "sessionId": "0851de47-b98e-4526-b049-cf20c1a3bc93"
6}

Check the Status of the Portrait 

With this request, the client application checks the status of the submitted portrait.

The client application can use this API to implement polling and go to the next steps only when being certain the portrait’s status is VERIFIED or prompt the user to retry with another portrait capture.

The request looks like this:

Shell
1curl -X GET \
2https://[URL_MAIN_PART]/gips/v1/identities/[IDENTITY_ID]/status/[PORTRAIT_ID] \
3-H 'apikey: [APIKEY_VALUE]'

Sample response:

JSON
1{
2  "status": "VERIFIED",
3  "type": "PORTRAIT",
4  "id": "12971f18-16ce-4a10-890a-bda5ffc7ecd7"
5}

Values for status can be:

• VERIFIED - document or face has successfully been verified. When VERIFIED, a document or face is scored on a scale of 1 to 4.

  • LEVEL1 - low confidence
  • LEVEL2 - medium confidence
  • LEVEL3 - high confidence
  • LEVEL4 - very high confidence

• INVALID - document or face is considered invalid after the checks performed

• NOT_VERIFIED - document or face was processed, but not enough checks were performed to take a decision, most of the time due to bad quality of the image, or an unsupported document type

• PROCESSING - evidence is currently being processed by the service

• ADJUDICATION - evidence is currently being reviewed by a human expert

Check the status of the identity 

With this request, the client application can check the status of the identity and see what level of assurance (LOA) has been reached.

The request looks like this:

Shell
1curl -X GET \
2https://[URL_MAIN_PART]/gips/v1/identities/[IDENTITY_ID] \
3-H 'Content-Type: application/json' \
4    -H 'apikey: [APIKEY_VALUE]'

Sample response:

JSON
1{
2  "globalStatus": {
3    "id": "gips-c386c92e-fd7a-4024-bb41-b0f2aab7540c",
4    "status": "EXPECTING_INPUT",
5    "levelOfAssurance": "LOA2",
6    "creationDateTime": "2022-12-20T14:46:27.2675744",
7    "evaluationDateTime": "2022-12-20T14:55:24.927849",
8    "nameReferenceEvidenceId": "a0416ffd-1ecf-4e0c-910d-b4192e963011",
9    "portraitReferenceEvidenceId": "a0416ffd-1ecf-4e0c-910d-b4192e963011",
10    "upgradePaths": {}
11  },
12  "consents": [
13    {
14      "consentId": "5d2a3c74-c3eb-46c9-ae00-a44eaef58399",
15      "approved": true,
16      "type": "PORTRAIT",
17      "validityPeriod": {
18        "from": "2018-01-01",
19        "to": "2021-06-08"
20      }
21    }
22  ],
23  "attributes": [
24    {
25      "evidenceId": "f0fc970b-f584-4a7a-bb12-6a8640cc1bcc",
26      "submitDateTime": "2020-12-08T19:51:36.7790737",
27      "type": "ATTRIBUTES",
28      "evidenceStatus": {
29        "evaluationDateTime": "2020-12-08T19:56:38.708744",
30        "status": "VERIFIED",
31        "strength": "LEVEL5",
32        "score": "LEVEL2",
33        "isAdjudicable": false
34      },
35      "attributesData": {
36        "givenNames": [
37          {
38            "value": "CHRISTOPHE",
39            "verified": true
40          }
41        ],
42        "surname": {
43          "value": "ULYSSE",
44          "verified": true
45        },
46        "fullname": {
47          "value": "CHRISTOPHE ULYSSE",
48          "verified": true
49        },
50        "dateOfBirth": {
51          "value": "1960-04-10",
52          "verified": true
53        },
54        "gender": {
55          "value": "M",
56          "verified": true
57        },
58        "nationality": {
59          "value": "FRA",
60          "verified": true
61        },
62        "eyeColor": {
63          "value": "GRAY",
64          "verified": true
65        },
66        "height": {
67          "value": "6' 6",
68          "verified": true
69        }
70      }
71    }
72  ],
73  "addresses": [
74    {
75      "evidenceId": "cfbad0fa-0905-4059-b877-73b98fa53c6e",
76      "submitDateTime": "2020-12-08T19:51:35.3634557",
77      "type": "ADDRESS",
78      "evidenceStatus": {
79        "evaluationDateTime": "2020-12-08T19:56:38.708744",
80        "status": "VERIFIED",
81        "strength": "LEVEL5",
82        "score": "LEVEL2",
83        "isAdjudicable": false
84      },
85      "referenceIds": ["a0416ffd-1ecf-4e0c-910d-b4192e963011"],
86      "addressData": {
87        "streetDetails": {
88          "streetLines": ["12 COTTONWOOD RD", "SUITE 1001"],
89          "verified": true
90        },
91        "postcode": "12345",
92        "city": "EMPIRE",
93        "state": "NV",
94        "country": "USA",
95        "verified": true
96      }
97    }
98  ],
99  "idDocuments": [
100    {
101      "evidenceId": "a0416ffd-1ecf-4e0c-910d-b4192e963011",
102      "submitDateTime": "2020-12-08T19:51:35.3634547",
103      "type": "PASSPORT",
104      "evidenceStatus": {
105        "evaluationDateTime": "2020-12-08T19:56:38.708744",
106        "status": "VERIFIED",
107        "strength": "LEVEL4",
108        "score": "LEVEL2",
109        "isAdjudicable": true,
110        "positiveIndicators": [
111          "BIOMETRIC_MATCHING_CHECK_OK",
112          "BIOMETRIC_QUALITY_CHECK_OK",
113          "MODEL_RECOGNIZED_OK",
114          "HIGH_TEMPLATE_OK",
115          "CB2D_FIELDS_SYNTAX_OK",
116          "DOCUMENT_BARCODE_PARSING_OK",
117          "LOW_TEMPLATE_OK",
118          "VISUAL_SECURITY_OK",
119          "MRZ_CHECKSUMS_OK",
120          "PHOTOCOPY_DETECTION_OK",
121          "PERSONAL_NUMBER_CHECKSUMS_OK",
122          "MODEL_COLOR_MATCHING_OK",
123          "PORTRAIT_OK",
124          "LCD_DETECTION_OK",
125          "ESFX_OK",
126          "OCRX_OK",
127          "SIDES_DATA_CONSISTENCY_OK",
128          "DOC_EXPIRATION_DATE_OK",
129          "BIRTHDATE_VALID_OK",
130          "DOC_ISSUING_COUNTRY_OK",
131          "OCR_DOCNUM_OK",
132          "MODEL_EXPIRATION_DATE_OK",
133          "EMISSION_COUNTRY_OK",
134          "MRZ_PRESENCE_OK",
135          "MRZ_ALIGNEMENT_OK",
136          "PHOTO_LOCATION_OK",
137          "DOCUMENT_CLASSIFIER_OK",
138          "MRZ_FIELDS_SYNTAX_OK",
139          "SIDES_MODEL_CONSISTENCY_OK",
140          "DOC_NATIONALITY_OK",
141          "MODEL_VALID_OUT_OF_COUNTRY_OK",
142          "OCR_FIRSTNAMES_OK",
143          "DOC_SPECIMEN_OK",
144          "OCR_LASTNAME_OK",
145          "OCR_BIRTHDATE_OK",
146          "EMISSION_DATE_OK",
147          "OCR_ISSUING_DATE_OK",
148          "BLUR_IMAGE_QUALITY_FRONT_OK",
149          "EXPIRATION_DATE_CONSISTENCY_OK",
150          "PAPER_COPY_OK",
151          "OCR_EXPIRATION_DATE_OK",
152          "ISSUING_DATE_VALIDITY_OK",
153          "GLARE_IMAGE_QUALITY_FRONT_OK",
154          "IMAGE_FRONT_DPI_CHECK_OK",
155          "OCR_SEX_OK",
156          "OCR_FULLNAME_OK"
157        ],
158        "warningIndicators": [
159          "LOW_IMAGE_QUALITY_FRONT_WARNING",
160          "KEYSTONE_IMAGE_QUALITY_FRONT_WARNING",
161          "BLUR_IMAGE_QUALITY_BACK_WARNING",
162          "GLARE_IMAGE_QUALITY_BACK_WARNING"
163        ],
164        "unverifiedIndicators": [
165          "DOCUMENT_NUMBER_VALIDITY_UNVERIFIED",
166          "COMPROMISED_DOCUMENT_CHECK_UNVERIFIED",
167          "TEXTURE_ANALYSIS_UNVERIFIED",
168          "MRZ_BARCODE_CROSSCHECK_UNVERIFIED"
169        ]
170      },
171      "idDocumentData": {
172        "idDocumentType": "PASSPORT",
173        "idDocumentNumber": "08CD50338",
174        "issuingCountry": "FRA",
175        "issuingState": "WA",
176        "issuingDate": "2005-09-01",
177        "expiryDate": "2021-03-18",
178        "personalAttributes": {
179          "givenNames": [
180            {
181              "value": "CHRISTOPHE",
182              "verified": true
183            }
184          ],
185          "surname": {
186            "value": "ULYSSE",
187            "verified": true
188          },
189          "fullname": {
190            "value": "CHRISTOPHE ULYSSE",
191            "verified": true
192          },
193          "dateOfBirth": {
194            "value": "1960-04-10",
195            "verified": true
196          },
197          "gender": {
198            "value": "M",
199            "verified": true
200          },
201          "nationality": {
202            "value": "FRA",
203            "verified": true
204          },
205          "eyeColor": {
206            "value": "GRAY",
207            "verified": true
208          },
209          "height": {
210            "value": "6' 6",
211            "verified": true
212          }
213        },
214        "address": {
215          "streetDetails": {
216            "streetLines": ["12 COTTONWOOD RD", "SUITE 1001"],
217            "verified": true
218          },
219          "postcode": "12345",
220          "city": "EMPIRE",
221          "state": "NV",
222          "country": "USA",
223          "verified": true
224        },
225        "mrz": [
226          "P<FRAULYSSE<<CHRISTOPHE<<<<<<<<<<<<<<<<<<<<<",
227          "08CD503380FRA6004103M1806058<<<<<<<<<<<<<<06"
228        ]
229      }
230    }
231  ],
232  "portrait": {
233    "evidenceId": "cf4551b5-988e-4ac6-97f6-6c74f1ab908e",
234    "submitDateTime": "2020-12-08T19:54:51.2122999",
235    "type": "PORTRAIT",
236    "evidenceStatus": {
237      "evaluationDateTime": "2020-12-08T19:56:38.708744",
238      "status": "VERIFIED",
239      "strength": "LEVEL4",
240      "score": "LEVEL2",
241      "isAdjudicable": true,
242      "positiveIndicators": [
243        "BIOMETRIC_MATCHING_CHECK_OK",
244        "BIOMETRIC_LIVENESS_CHALLENGE_OK"
245      ]
246    },
247    "portraitQuality": true,
248    "portraitData": {
249      "source": "LIVE_CAPTURE_VIDEO",
250      "channel": "nativeSDK"
251    }
252  }
253}

Check the levelOfAssurance value to see the current score of the identity created.

The client application can also check the status of all submitted data:

• Portrait is summarized in the “portrait” structure.

• Identity document is summarized in the “idDocuments” structure.

The rest of the response contains various information like the upgrade path to improve LOA or attributes (personal information extracted from documents or submitted by the user).

Ending the process and retrieving the proof file 

With this request, the client application terminates the proofing process and retrieves all the information that the service has gathered and generated.

In response to this request, the client application receives an archive file. The client application can archive this file for audit purposes and use its content as a reference for the user's identity.

Getting the proof terminates the transaction and the service applies the deletion policy to the personal information gathered during the session.

The request looks like this:

Shell
1curl -X GET \
2https://[URL_MAIN_PART]/gips/v1/identities/[IDENTITY_ID]/proof \
3-H 'apikey: [APIKEY_VALUE]' -o proof

API feedback 

This section contains error codes and indicators.

Error codes 

Error codes in relation to face matching:

Indicators 

ID&V is configured by default, with the following blocking indicators:

Scoring 

Once a portrait has been submitted, results of the biometric matching are combined by the Identity Proofing service to increase the score of the portrait evidence.

Here is the summary of the portrait image scoring:

Example:

Evidence references and their scoring and level indications:

• PASSPORT, Document Authentication only: Passport status is VERIFIED at LEVEL2 then Portrait status is also VERIFIED at LEVEL2
• Driver's License (US), Document Authentication + Issuing Source Verification: If Driver's License status is VERIFIED at LEVEL3, then Portrait status is also VERIFIED at LEVEL3
• PASSPORT, Document Authentication only: if Passport status is VERIFIED at LEVEL2, then Portrait status is also VERIFIED at LEVEL2
• Driver's License (US), Document Authentication + Issuing Source Verification: if Driver's License status is VERIFIED at LEVEL3, then Portrait status is also VERIFIED at LEVEL3

Decision rules and reference portrait election 

To check that the user is the same person as the person on the identity document, ID&V performs a biometric comparison between the submitted self-portrait image and all the submitted evidences that contain a portrait image (such as passport, ID card, driver’s license):

• If the biometric matching score is above the configured tolerance threshold, then the portrait images are considered to match.

• If not, portrait images are not considered to match.

When multiple evidences are submitted, ID&V selects the reference portrait image as follows:

• select the evidence with the highest verification score.

• If multiple evidences have the same verification score, then select the one with the highest coding quality score.

• If the evidences have the same quality score too, then select the one with the highest matching score.

• Finally, if no single evidence has been elected at this stage, select the most recently received evidence.

ID&V’s face matching process

Face Matching Configuration 

ID&V is configured with a tolerance threshold for biometric matching that determines whether a biometric comparison matches or not; and it will incur a false acceptance rate (FAR) and a false rejection rate (FRR).

Depending on use case constraints, an acceptable balance between FAR and FRR is determined using the tolerance threshold. The tolerance threshold can be configured, but should take into account the following trade-off:

• Low FAR implies high FRR

• Low FRR implies high FAR

FRR and FAR defined:

Face Matching trade-off Graphical representation