Using NFC for Document Authentication 

Purpose 

This document describes how to authenticate ICAO 9303 Documents by reading the NFC chip on ID NFC-readable document and using the IDEMIA Native NFC SDK and its API to perform the verifications and security checks.

Requirements 

NFC document reading is initiated by the client application which creates the document reading session.

ID&V responds with the session identifier that can be used by a mobile device for initializing the reading process with the NFC native SDK.

To execute the scenarios, the client application needs:

• API Keys and URLs to access the ID proofing service

  • GIPS-RS key for Back-end to Back-end communication

  • GIPS-UA key for the end-user-facing application to ID Proofing Back-end communication

• The IDEMIA Native NFC SDK which executes the reading process between the NFC-readable document and the server

Details about the NFC document reading with the IDEMIA Native NFC SDK are available:

• for iOS: IDEMIA Native NFC SDK - iOS
• for Android: IDEMIA Native NFC SDK - Android

Scenario Overview 

This scenario describes how a client application can verify an ICAO 9303 ID NFC-readable document.

There are two main scenarios for verifying a NFC-readable document of an end-user:

• NFC Document Chip authentication only

• ID Document (ID) capture authentication followed by NFC Document Chip authentication

NFC Document Chip Authentication Only 

Steps Overview

1. Create the identity.
2. Initialize the NFC Document authentication.
3. Start the NFC Document reading process.
4. Retrieve the document authentication results and identity proof results.

This example uses an ID NFC-readable document.

Steps

Step 1: Create the identity.

Create an identity on the ID proofing server that will receive all of the data and gather the verification results related to this identity. The "identity" will relates to the end-user presenting it.

Step 2: Initialize the NFC Document authentication.

Initialize a session with the service to authenticate a NFC-readable document.

• The client application:

  • Sends a request to Identity Document Capture & Verification (ID&V) for starting the NFC Document authentication.

    • ID&V creates a session in the NFC server.

    • ID&V returns to the client application, the sessionId to be used by the SDK to perform the NFC Document reading with the NFC server.

Step 3: Start the NFC Document reading process.

The smart device can use a unique session id to start the document reading session with the NFC server, poll scripts, and provide the script execution response(s).

• The client application will read document with the NFC native SDK.

  • The NFC Document reading process can be found under the NFC Documentation section in IDEMIA's Developer Portal.

• The NFC server will send a push request which contains the document data to ID&V as soon as the document reading is complete.

• ID&V then performs the document data decryption and extracts the end-user's personally identifiable information (PII), document information, and the security checks performed.

Step 4: Get the document status and retrieve the proof results.

The client application can retrieve the result of the document reading and authentication:

• If the document reading is complete and the security checks perform successfully, the document status is VERIFIED and the document is assigned a score.

• If the document reading is complete and the security checks fail, the document status is INVALID and the document is assigned a LEVEL0 score and an error code.

• If the document reading is not complete, the document status is NOT_VERIFIED and the document is assigned a LEVEL0 score.

The end-user can submit additional piece of identity evidences in an attempt to increase the level of confidence in the ID.

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.

Document Capture then NFC Document Authentication 

Steps Overview

1. Create the identity.
2. Submit an ID capture.
3. Initialize the NFC Document authentication.
4. Start the NFC Document reading process.
5. Retrieve the document authentication results and the identity proof results.

This example uses an ID NFC-readable document.

Steps

Step 1: Create the identity.

Create an identity on the ID proofing server that will receive all of the data and gather the verification results related to this identity. The "identity" will relates to the end-user presenting it.

Step 2: Submit an ID capture.

Send the identity document images for verification.

• ID&V performs the document authentication and extracts the end-user's personally identifiable information (PII) and document information;

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

Step 3: Initialize the NFC Document authentication.

Initialize a session with the service to authenticate a NFC-readable document.

• The client application:

  • Sends a request to ID&V for starting the NFC Document authentication.

    • ID&V creates a session in the NFC server.

    • ID&V returns to the client application, the sessionId to be used by the SDK to perform the NFC Document reading with the NFC server.

Step 3: Start the NFC Document reading process.

The mobile device can use unique session id to start document reading session with the NFC server, poll scripts, and provide the script execution response(s).

• The client application will read the document with the IDEMIA Native NFC SDK.

  • The NFC Document reading process can be found under the NFC Documentation in the IDEMIA's Developer Portal.

• The NFC server will send a push request which contains the document data to ID&V as soon as the document reading is complete.

• ID&V performs the document data decryption and extracts the end-user's personally identifiable information (PII), document information, and the security checks performed.

• ID&V makes the combination of the document data attributes extracted during the document capture authentication and the document data attributes extracted during the NFC Document authentication.

• ID&V then makes a combination of indicators raised during the document capture authentication and indicators raised during the NFC Document authentication.

Step 4: Get the document status and retrieve the proof results.

The client application can retrieve the result of the Document reading and authentication:

• If the reference ID is valid, the document status is VERIFIED, and the document is assigned a score.

• If the reference ID is not valid, the document status is INVALID, and the document is assigned a LEVEL0 score and an error code.

The end-user can submit additional piece of identity evidences to increase the level of confidence in the ID.

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 the 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-38cbf31c-0aaf-4976-8785-a84d4dbd401d",
3  "status": "EXPECTING_INPUT",
4  "levelOfAssurance": "LOA0",
5  "creationDateTime": "2020-12-09T22:21:06.4694814",
6  "evaluationDateTime": "2020-12-09T22:21:10.5844854",
7  "upgradePaths": {}
8}

Submit a Document Capture 

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

• Passport

• Identity card

• Driver's license

• Resident card

The request looks like this:

Shell
1curl -X POST \
2 https://[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": "a8d00f36-d967-4571-afe8-6cfd0fe4b98e"
5}

Check Document Status 

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

The request looks like this:

Shell
1curl -X GET \
2 https://[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": "a8d00f36-d967-4571-afe8-6cfd0fe4b98e"
5}

Values for status can be:

• VERIFIED - means that document/face has successfully been verified. When VERIFIED, a Document/Face is scored on a scale of 1 to 4.

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

• INVALID - means that the document/face is considered invalid after the checking process completes

• NOT_VERIFIED - means that the document/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 - means that the evidence is currently being processed by the service

• ADJUDICATION - means that the evidence is currently under review by a human expert

Initialize the NFC Document authentication 

With this request, the client application initializes a NFC Document reading session by sending the machine readable zone (MRZ) of an ID to create the NFC reading session. This allows the NFC Document reading and authentication processes to start.

The service provides a NFC session identifier to start the reading process and to execute the script via a NFC protocol between the mobile device application and the NFC server. This session identifier and the result links to the rest of the end-user's identity.

The request looks like this:

Shell
1curl -X POST \
2   http://[URL_MAIN_PART]/gips/v1/identities/[IDENTITY_ID]/id-documents/nfc-session \
3   -H 'Content-Type: application/json' \
4   -H 'apikey: [APIKEY_VALUE]' \
5   -d '{
6           "mrz": [
7               "P<AUSHAPPY<CITIZEN<<FRED<WIREMU<JOHN<<<<<<"
8           ]
9       }'

Description of JSON fields in the payload:

Sample response:

JSON
1{
2  "status": "PROCESSING",
3  "type": "ID_DOCUMENT",
4  "id": "722cb215-d83e-443b-980c-23b9effc3bbc",
5  "sessionId": "nfc_session_Id"
6}

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 \
2 https://[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-38cbf31c-0aaf-4976-8785-a84d4dbd401d",
4    "status": "EXPECTING_INPUT",
5    "levelOfAssurance": "LOA1",
6    "creationDateTime": "2020-12-09T22:21:06.4694814",
7    "evaluationDateTime": "2020-12-09T22:33:36.3246557",
8    "nameReferenceEvidenceId": "722cb215-d83e-443b-980c-23b9effc3bbc",
9    "upgradePaths": {}
10  },
11  "attributes": [
12    {
13      "evidenceId": "72cced44-d2c8-4347-b755-321ac21972dd",
14      "submitDateTime": "2020-12-09T22:33:36.3216661",
15      "type": "ATTRIBUTES",
16      "evidenceStatus": {
17        "evaluationDateTime": "2020-12-09T22:33:36.3246557",
18        "status": "VERIFIED",
19        "strength": "LEVEL5",
20        "score": "LEVEL3",
21        "isAdjudicable": false
22      },
23      "attributesData": {
24        "givenNames": [
25          {
26            "value": "FRED",
27            "verified": true
28          },
29          {
30            "value": "WIREMU",
31            "verified": true
32          },
33          {
34            "value": "JOHN",
35            "verified": true
36          }
37        ],
38        "surname": {
39          "value": "HAPPY CITIZEN",
40          "verified": true
41        },
42        "dateOfBirth": {
43          "value": "1963-11-01",
44          "verified": true
45        },
46        "gender": {
47          "value": "M",
48          "verified": true
49        },
50        "nationality": {
51          "value": "AUS",
52          "verified": true
53        }
54      }
55    }
56  ],
57  "idDocuments": [
58    {
59      "evidenceId": "722cb215-d83e-443b-980c-23b9effc3bbc",
60      "submitDateTime": "2020-12-09T22:32:29.1736816",
61      "type": "PASSPORT",
62      "evidenceStatus": {
63        "evaluationDateTime": "2020-12-09T22:33:36.3246557",
64        "status": "VERIFIED",
65        "strength": "LEVEL4",
66        "score": "LEVEL3",
67        "isAdjudicable": false,
68        "positiveIndicators": [
69          "TERMINAL_AUTHENTICATION_CHECK_OK",
70          "PASSIVE_AUTHENTICATION_CHECK_OK",
71          "PASSIVE_AUTHENTICATION_HASH_CHECK_OK",
72          "PASOD_SIGNATURE_CHECK_OK",
73          "DATA_GROUP1_CHECK_OK",
74          "BASIC_ACCESS_CONTROL_CHECK_OK",
75          "ACTIVE_AUTHENTICATION_CHECK_OK",
76          "DOC_EXPIRATION_DATE_OK",
77          "CHIP_AUTHENTICATION_CHECK_OK",
78          "PASSWORD_AUTHENTICATED_CONNECTION_ESTABLISHMENT_CHECK_OK",
79          "PASSIVE_AUTHENTICATION_DOCUMENT_SIGNER_CHECK_OK"
80        ]
81      },
82      "idDocumentData": {
83        "idDocumentType": "PASSPORT",
84        "idDocumentNumber": "AZ1234567",
85        "issuingCountry": "AUS",
86        "expiryDate": "2025-04-08",
87        "personalAttributes": {
88          "givenNames": [
89            {
90              "value": "FRED",
91              "verified": true
92            },
93            {
94              "value": "WIREMU",
95              "verified": true
96            },
97            {
98              "value": "JOHN",
99              "verified": true
100            }
101          ],
102          "surname": {
103            "value": "HAPPY CITIZEN",
104            "verified": true
105          },
106          "dateOfBirth": {
107            "value": "1963-11-01",
108            "verified": true
109          },
110          "gender": {
111            "value": "M",
112            "verified": true
113          },
114          "nationality": {
115            "value": "AUS",
116            "verified": true
117          }
118        },
119        "mrz": ["P<AUSHAPPY<CITIZEN<<FRED<WIREMU<JOHN<<<<<<"]
120      }
121    }
122  ]
123}

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

The client application has the ability to check the status of all the 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 end-user).

Ending the Process and Retrieving the Proof File 

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

In response to this request, the client application receives an archive file. The client application may archive this file for audit purpose and use its content as a reference for the end-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 \
2 https://[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 raised when authenticating a NFC-readable document.

Error Codes 

Error codes in relation to NFC Document authentication:

Indicators 

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

Scoring 

Once a NFC-readable document has been submitted, results of the checks are combined by the ID proofing service to increase the score of ID.

Here is the summary of the ID scoring of ID NFC-readable document: