Overview

IDLive™ Doc - Product Summary¶

When onboarding or authenticating users remotely, a user may be asked to submit government-issued documents as proof of their identity. However, without verifying the liveness of the provided images, attackers may instead present an image of a document they do not physically possess, generate an image of a document that never existed, or manipulate an otherwise-authentic document. These so-called "presentation attacks" reduce a business' confidence in digital identity, while increasing losses from fraud and inviting greater regulatory scrutiny. In response to these threats, IDLive™ Doc is a document liveness solution which identifies presentation attacks efficiently and automatically.

IDLive™ Doc determines whether a submitted image represents a real, unaltered document that was presented to the capturing device. It supports government-issued identity documents from around the world, including ID Cards, Passports and Drivers' Licenses. Unlike other forms of ID verification, IDLive™ Doc is largely document-agnostic, and does not require constant retraining to support each new document iteration. Additionally, IDLive™ Doc relies solely on a single image frame. It does not require that the user perform any additional action or movements in order to evaluate the image.

The types of attacks that IDLive™ Doc prevents or will prevent are listed below:

• Screen Replay Attack - An attacker captures an image or video of a document. Later, the attacker presents that image or video back to a verification system, implying that they have possession of the document when they do not. Although screen replays are not always malicious in nature, a replayed document image cannot be used to corroborate a user's identity.
• Printed Copy Attack - An attacker presents to the camera a physical, printed document that was designed to imitate a government-issued ID. The printed document may be a photocopy of an authentic document (in which case the attack's purpose is similar to a screen replay), or the document may be altered/forged.
• Portrait Substitution Attack - An attacker presents an authentic ID, except that the identifying photo has been replaced. This attack is often an attempt to associate a victim's identity with the attacker's likeness, in order to trick human agents and/or facial recognition systems.
• Digital Manipulation Attack - An attacker digitally alters a document using image editing software or deep learning models. These manipulations may involve modifying text, swapping photos, altering seals or holograms, or generating entirely synthetic content. The manipulated file can be submitted directly in an injection attack or presented on a screen or as a printed copy, combining methods to evade detection.

Software Packaging and Pipelines¶

IDLive™ Doc assumes that an image has been captured by the rear-facing camera of a mobile device, and is optimized for that use case. The captured image may then be submitted for liveness evaluation in one of three ways:

• IDLive™ Doc Server - Document Attack Prevention Service as a Docker image for server-based deployment using an HTTP interface, typical of a microservices architecture
• IDLive™ Doc SDK - C99/C++11 API SDK with Python and Java wrappers, for Linux and Windows 64-bit applications
• IDLive™ Doc Cloud API - This option is intended for product evaluations. For customer privacy, no transactional image data is retained by ID R&D servers.

The primary output of IDLive™ Doc is a probability representing the likelihood that a given image is live. For example, the default pass-fail threshold is a probability of 50%, or 0.5. However, you may wish to change (or dynamically adjust) this threshold to account for transactions with varying levels of risk.

The remainder of this document contains technical requirements, image samples, and API usage instructions. Please consult the developer checklist to ensure an easy, efficient integration.

Available Pipelines:

• Screen Replay Attack Vector
• screen-replay_2024-09 - This pipeline is our latest release and the recommended algorithm for detecting Screen Replay attacks.
• screen-replay_2024-05 - This pipeline is a previous version of the Screen Replay algorithm, now deprecated.
• Printed Copy Attack Vector
• printed-copy_2024-09 - This pipeline is our latest release and the recommended algorithm for detecting Printed Copy attacks. "REGULAR" and "HARD" calibrations are supported. Note: images of document backs are not supported at this time.
• printed-copy_2024-01 - This pipeline is a previous version of the Printed Copy algorithm, now deprecated.
• Portrait Substitution Attack Vector
• portrait-substitution_2024-09 - This pipeline is our latest release and the recommended algorithm for detecting Portrait Substitution attacks. "REGULAR" and "HARD" calibrations are supported.
• portrait-substitution_2024-05 - This pipeline is a previous version of the Portrait Substitution algorithm, now deprecated.
• Digital Manipulation Attack Vector
• digital-manipulation_2024-11 - This pipeline is our latest release and the recommended algorithm for detecting Digital Manipulation attacks. "SOFT", "REGULAR" and "HARD" calibrations are supported.
• digital-manipulation_2022-11 - This pipeline is a previous version of the Digital Manipulation algorithm, now deprecated.

Data Requirements¶

Image Format Requirements¶

ID R&D's anti-spoofing algorithms have been developed using document images of varying quality, taken in a variety of orientations and lighting conditions. Although IDLive™ Doc supports a wide range of image quality, high-resolution images captured under optimal lighting conditions will afford the greatest accuracy.

Supported Image Size and Compression

• Minimum resolution: Full HD, also known as FHD or 1080p (1920x1080 px)
• Maximum compression: Single pass at JPEG 70, although uncompressed images are strongly recommended. Images should never be compressed more than once.

IDLive™ Doc supports images compressed up to the JPEG 70 standard. However, while the resulting compression artifacts may be invisible to the naked eye, they may still be significant to the anti-spoofing algorithm. The larger the JPEG number (JPEG 80, JPEG 90, etc.), the less compression performed and therefore the higher quality retained by the image. We recommend minimal compression, preferably of a lossless variety such as PNG.

Supported Image Formats:

• Windows bitmaps - *.bmp, *.dib
• JPEG files - *.jpeg, *.jpg, *.jpe
• JPEG 2000 files - *.jp2
• Portable Network Graphics - *.png
• WebP - *.webp
• Portable image format - *.pbm, *.pgm, *.ppm *.pxm, *.pnm
• PFM files - *.pfm
• Sun rasters - *.sr, *.ras
• TIFF files - *.tiff, *.tif
• OpenEXR Image files - *.exr
• Radiance HDR - *.hdr, *.pic

Image Content Requirements¶

• Only identity documents are officially supported. This includes booklets (e.g., passports) and card document fronts (including driver's licenses and identity cards). Although IDLive Doc can successfully process other document images, the accuracy of the findings may be reduced. For more information about specific document types and best practices, please consult your ID R&D representative.
• The image must preserve a border around the document equal to at least 5% of the document's width. Tightly cropped images are more difficult to accurately evaluate for liveness.
• Image blurring due to motion during capture may lead to the rejection of legitimate, live documents (BPCER).
• Image smoothing and texture filtering can significantly increase the approval of spoofed images (APCER).
• Fish-eye lenses (perspective distortion) is not supported by this product.
• Sharp glare on the document or image background, like from overhead lighting and direct sunlight, may increase the risk of rejection (BPCER).
• Poor lighting, artificially colored lighting, and desaturated/grayscale images may significantly increase the risk of rejection (BPCER).

The IDLive™ Doc product automaticaly checks whether the requirements are met and generates a set of image quality warnings or a hard error if needed. The generated values are returned as part of the liveness check result through the API. The tables below list and explain the hard error and image quality warning values which can be generated by the product.

Hardware Requirements¶

Below are the recommended hardware configurations for the CPU and GPU releases.

Reference hardware configurations are c5.4xlarge AWS EC2 instance ($0.68/hour for on-demand instance in us-east-2 region) for the CPU release and g4dn.xlarge AWS EC2 instance ($0.526/hour for on-demand instance in us-east-2 region) for the GPU release.

Expected Performance¶

The table below outlines the expected number of transactions per second (TPS) provided by both CPU and GPU versions of the Docker distribution running on a corresponding recommended hardware configuration (c5.4xlarge AWS EC2 instance for the CPU release and g4dn.xlarge AWS EC2 instance for the GPU release). The input image has FullHD (1920 × 1080) resolution. The assessment was made for the POST /check_liveness?configuration=<pipeline(s)> API endpoint.

Init time¶

The table below outlines the expected initialization time (seconds) by both CPU and GPU versions of the Docker distribution running on a corresponding recommended hardware configuration (c5.4xlarge AWS EC2 instance for the CPU release and g4dn.xlarge AWS EC2 instance for the GPU release).