Document authentication methods 

Identity proofing stands on two pillars: document authentication and biometric verification. Document authentication performs various procedures to verify the authenticity of the document, and as a result ensuring that the document itself is valid.

Document capture 

Document capture provides the user with steps to guide them through the evidence capture process and video stream analysis using their mobile phone camera. The Capture SDK analyzes this stream and detects when to capture an image with optimal quality. This assistance is critical to ensure superior image quality capture, and as a result provides optimal document validation and authentication. This image capture and video stream analysis includes detection of:

  • Saturated reflections (white pixels)
  • Incorrect framing (too far, too close, incomplete document, significant trapezoid effect)
  • Blurring due to user movement

An image is acquired only when all quality criteria are met. IDEMIA recommends embedding the IDEMIA SmartDoc SDK in the service provider's own app to allow the applicant to conveniently and accurately capture the evidence document. However, it is also possible to directly submit a picture of the document to the Identity Proofing platform using its APIs.

Document authentication 

Once an optimal quality image is captured, the IDEMIA ID&V offers multiple document authentication solutions ranging from automated, hybrid, or manual via human adjudication models. These models are based on customer requirements for speed, confidence level, and cost. The automated model is fast and cost effective, but provides a lower confidence level compared to the hybrid or manual models.

Solution
Description
AutomatedThe algorithm verifies the document and delivers results. The document can only be verified automatically.
HybridThe algorithm verifies the document based on predefined rules. In case an abnormality is detected, it sends the documents to a verifier for manual adjudication. The document can be verified in two ways: fully automated via the engine or through a two-step engine and human verification in case a fraud risk is detected.
ManualThe solution classifies the document and send it to human adjudication. Verification is only completed by a human.

How to select a document authentication solution 

To position the adequate document authentication solution, IDEMIA follows these key criteria based on customer requirements:

Document Authentication Solution

Procedures 

Automated document authentication

Processes the digital image of a document and data extraction (the evidence holder’s attributes, including photo when applicable, and evidence details) in order to authenticate it. The optical document verification is typically performed for the following pieces of evidence:

  • IDENTITY_CARD
  • DRIVING_LICENSE
  • ID_DOCUMENT
  • RESIDENT_CARD

Each document is analyzed in a number of steps based on the document type. The following is the list of checks performed when these are present and applicable:

  • Classification

  • Document type, issuing authority, version, and class

  • Data extraction and validation

  • Barcode (PDF417)

  • Machine-readable zone (MRZ) consistency, MRZ versus VIZ, and MRZ versus Barcode, MRZ font anomalies

  • Barcode versus Visual Inspection Zone (VIZ) check and barcode versus ESF check

  • Cropped ID and portrait

  • Optical Character Recognition (OCR) on the Visual Inspection Zone (VIZ)

  • Security features

  • Visible patterns check: Deep Pattern Matching (DPM), Enhanced Security Features (ESF), and Linecode

  • Data validation

  • Document template relative to issuing date

  • Tampered photos

  • Tones and colors

  • Original ID presence

    Note: Not all checks are available on all types of documents.

Indicators

The results of these various checks, when communicated to the relying party, are called indicators. Indicators help the relying party understand which checks have been performed on an identity evidence and why an identity evidence has been assigned a status and a score. For example:

  • A fraud is detected
  • MRZ checksum failed

Each indicator is associated with a status:

Status
Definition
UNVERIFIEDControl was not performed
OKEvidence successfully passed the control
WARNINGControl was performed and there may be a problem with this evidence
FAILEDEvidence failed the control

Depending on their status, indicators are defined as either “blocking” or “non-blocking", based on configuration. They are used for scoring and for fraud detection during the analysis step. Blocking indicators appear in the REST API responses to highlight why an evidence is invalid. In the identity proof file, all the indicators raised are available.

IDEMIA has a key differentiator: Linecode and security features (ESF) are embedded by IDEMIA at the time of some US document issuance. Both ESF and Linecode allow IDEMIA to verify credential authenticity against the digital data present on these documents. IDEMIA holds the patent and is the exclusive provider of those technology, which detects, reads, parses, and validates these features.

Manual document authentication

When an identity document is sent to manual authentication through adjudication, a human operator verifies that the document image has not been manipulated — including photo substitution, characters replaced, and inconsistency with reference — and that this is not a paper or a screen copy. In case the evidence is rejected, the operator provides the rejection reason and creates an indicator accordingly.

When the ID is validated manually during manual checks, the document submitted (passport, driver's license, etc.) is compared to the reference portrait (template). In case a fraud attempt is detected, it triggers an alert.

Adjudication Process

Note: the decision logic step is configurable to create different profiles: fully automated or hybrid mode (only adjudicate doubts).

The adjudication can be used in the following situations:

  • To mitigate fraud risk (document authentication has raised some risks and the operator can mitigate them).
  • To verify features that cannot be detected by automated measures.

This service is used to strengthen verification by processing all documents in this manner, or by improving conversion rates of transactions rejected in the automatic process. Human adjudication can be performed in parallel with other forms of verification or afterwards.

Here's an example of human adjudication comparing the image capture with the reference portrait:

Human Adjudication Process

Note: IDEMIA offers full service adjudication, with opening times and types of documents as defined per project.

NFC document verification 

IDEMIA's Identity Proofing platform provides Near Field Communication (NFC) document verification. NFC refers to a set of communication protocols between two electronic devices over a distance of 4 cm or less. In identity proofing, this also sometimes refers to the newest electronic passports where critical information resides in a chip embedded in the passport and readable via NFC.

Applications can use the IDEMIA Native NFC SDK and its API to perform the verifications and security checks to verify ICAO 9303 passports by reading the NFC chip on a passport.

A typical use of this verification enables a client application to verify an ICAO 9303 NFC-readable identity document.

NFC document chip verification process:

NFC Verification

Steps to complete the NFC document verification process:

Step 1: Initiate the NFC document verification.

  • Relying service application initiate a session with ID&V service to verify a NFC-readable document.
  • Once initiated, it redirects the end user smart device to NFC API.

Step 2: Start the NFC document reading process.

  • The smart device uses IDEMIA NFC SDK to initiate the communication between ICAO 9303 document chip and IDEMIA ID&V backend.

  • Smart device is a pass-through, NFC document details are securely pulled, cyphered, from the chip to IDEMIA ID&V backend.

  • Cryptographic authentication of the document issuer and the contents of the NFC chip are verified in ID&V backend.

Step 3: Retrieve the document status and the identity proof.

  • The client application retrieves the result of the document reading and verification, including documents and identity details.

System of record verification 

For some pieces of evidence, it is possible to check the evidence directly with its issuing source. When available, the Identity Proofing platform compares data extracted from evidence submitted by the user against the issuing source’s System of Record (SoR) or a government agency database– also known as Government Identity Verification (GIV).

System of record verification is typically performed for categories of evidence such as DRIVING_LICENSE or IDENTITY_CARD.

The SoR validation service can be used in two ways:

  1. Document-capture-based submission: document and identity data are extracted from the document using optical character recognition (OCR) and the data sent for verification. The results of document authentication checks and SoR checks are combined by the Identity Proofing platform to increase the score of the document verification.
  2. Text-based submission: driver's license data is submitted as text in the web service request payload. In this case, only validation against the System of Record (SoR) is used for verification. Text-based submission may be used in the following cases:
    • The OCR fails to accurately capture card data, causing document-capture-based verification to fail. The service checks that the edit distance between extracted data and user-captured data is no greater than one character for the first name or last name.
    • The user has had a change of address but has not yet obtained an updated driver's license or equivalent identity card. In this case, the manually entered data is compared against the system of record.

Note: SoR verification compares a document to its authoritative data resource at the issuing source, thus ensuring that the document itself is valid. However, it does not ensure that the document identifies the individual who holds it. For that, this procedure must be paired with a procedure such as biometric verification.

Identity validation against an SoR 

Using the IDEMIA Identity Proofing platform API, an application can verify an individual’s identity by validating their ID against the SoR. The Identity Proofing platform provides services that connect to the various issuing sources and allows integrators to validate personal and document details. The Identity Proofing platform verifies that the data on the ID matches the data held by the SoR.

Supported issuing sources

ID&V supports the following issuing sources:

  • UK Document Checking Service (DCS)
  • Australian Document Verification System (DVS)
  • US Motor Vehicle Administrations (MVAs)

UK issuer verification

The supported document for the UK issuer verification is :

  • Passport

Australian issuer verification

The supported document for the Australian issuer verification are :

  • Passport
  • Driver's license
  • Resident card

Participating states in Australia are the following:

Jurisdiction
Australian Capital Territory
NSWNew South Wales
NTNorthern Territory
QLDQueensland
SASouth Australia
TASTasmania
VICVictoria
WAWestern Australia

US issuer verification

The supported documents for US issuer verification are :

  • Driver's license
  • Driver's permit
  • Identity cards

The service does not support all US jurisdictions for all documents. Additionally, some jurisdictions specify restrictions on which categories of users can conduct an identity check.

Jurisdiction support

The Identity Proofing platform is supported in participating US jurisdictions. Some jurisdictions restrict which users can conduct an identity check. Motor vehicle administrations in most jurisdictions support the verification of driver’s licenses and identity cards. A few jurisdictions only support the verification of driver’s licenses or a limited set of their identity documents as shown in the table.

Jurisdiction
Driver's License Support
Identity Card Support
Restriction
AKyesyesOnly government users supported
ALyesyesOnly government users supported
ARyesyesNo user restrictions
AZyesyesNo user restrictions
CAyesyesOnly government users supported
COyesyesNo user restrictions
CTyesyesNo user restrictions
DCyesyesNo user restrictions
DEyesnoNo user restrictions
FLyesyesNo user restrictions
GAyessomeNo user restrictions
HIyesyesNo user restrictions
IAyesyesNo user restrictions
IDyesyesNo user restrictions
ILyesyesNo user restrictions
INyesyesNo user restrictions
KSyesyesNo user restrictions
KYyesyesNo user restrictions
LAyesyesOnly government users supported
MAyesyesNo user restrictions
MDyesyesNo user restrictions
MEyesyesNo user restrictions
MIyesyesNo user restrictions
MNnonoNo user restrictions
MOyesyesNo user restrictions
MSyesyesNo user restrictions
MTyessomeNo user restrictions
NCyesyesNo user restrictions
NDyesyesNo user restrictions
NEyesyesNo user restrictions
NHnonoNo user restrictions
NJyesyesNo user restrictions
NMyesyesNo user restrictions
NVnonoNo user restrictions
NYyesyesOnly government users supported
OHyesyesNo user restrictions
OKyesyesNo user restrictions
ORyesyesNo user restrictions
PAyesyesRequires express written consent from the individual whose identity is being verified. It is the responsibility of the integrating service to collect and retain this consent.
RIyesyesNo user restrictions
SCyesyesOnly government users supported
SDyesyesNo user restrictions
TNyesyesNo user restrictions
TXyesyesNo user restrictions
UTyesyesOnly government users supported (SSA related)
VAyesyesNo user restrictions
VTyesyesNo user restrictions
WAyesyesNo user restrictions
WIyesnoNo user restrictions
WVnonoNo user restrictions
WYyessomeNo user restrictions

Trusted identity claim verification 

Using the OpenID Connect authentication protocol of the IDEMIA Identity Proofing platform API, applications can submit trusted identity claims. The submitted trusted identity claims are used to upgrade the level of assurance of an identity that has been submitted.