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 |
---|---|
Automated | The algorithm verifies the document and delivers results. The document can only be verified automatically. |
Hybrid | The 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. |
Manual | The 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:
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 |
---|---|
UNVERIFIED | Control was not performed |
OK | Evidence successfully passed the control |
WARNING | Control was performed and there may be a problem with this evidence |
FAILED | Evidence 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.
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:
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:
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:
- 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.
- 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 |
---|---|
NSW | New South Wales |
NT | Northern Territory |
QLD | Queensland |
SA | South Australia |
TAS | Tasmania |
VIC | Victoria |
WA | Western 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 |
---|---|---|---|
AK | yes | yes | Only government users supported |
AL | yes | yes | Only government users supported |
AR | yes | yes | No user restrictions |
AZ | yes | yes | No user restrictions |
CA | yes | yes | Only government users supported |
CO | yes | yes | No user restrictions |
CT | yes | yes | No user restrictions |
DC | yes | yes | No user restrictions |
DE | yes | no | No user restrictions |
FL | yes | yes | No user restrictions |
GA | yes | some | No user restrictions |
HI | yes | yes | No user restrictions |
IA | yes | yes | No user restrictions |
ID | yes | yes | No user restrictions |
IL | yes | yes | No user restrictions |
IN | yes | yes | No user restrictions |
KS | yes | yes | No user restrictions |
KY | yes | yes | No user restrictions |
LA | yes | yes | Only government users supported |
MA | yes | yes | No user restrictions |
MD | yes | yes | No user restrictions |
ME | yes | yes | No user restrictions |
MI | yes | yes | No user restrictions |
MN | no | no | No user restrictions |
MO | yes | yes | No user restrictions |
MS | yes | yes | No user restrictions |
MT | yes | some | No user restrictions |
NC | yes | yes | No user restrictions |
ND | yes | yes | No user restrictions |
NE | yes | yes | No user restrictions |
NH | no | no | No user restrictions |
NJ | yes | yes | No user restrictions |
NM | yes | yes | No user restrictions |
NV | no | no | No user restrictions |
NY | yes | yes | Only government users supported |
OH | yes | yes | No user restrictions |
OK | yes | yes | No user restrictions |
OR | yes | yes | No user restrictions |
PA | yes | yes | Requires 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. |
RI | yes | yes | No user restrictions |
SC | yes | yes | Only government users supported |
SD | yes | yes | No user restrictions |
TN | yes | yes | No user restrictions |
TX | yes | yes | No user restrictions |
UT | yes | yes | Only government users supported (SSA related) |
VA | yes | yes | No user restrictions |
VT | yes | yes | No user restrictions |
WA | yes | yes | No user restrictions |
WI | yes | no | No user restrictions |
WV | no | no | No user restrictions |
WY | yes | some | No 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.