DOT Digital Identity Service

v1.2.1

Overview

Digital Identity Service enables two main features:

  • Customer onboarding

  • Face biometrics

The customer onboarding is basic use-case of DOT. The customer provides his/her selfie, photos of his/her identity card and he/she should pass liveness detection. Provided data can be check for inconsistencies, and based on the check result, client decides if the customer will be onboard.

The biometric processing of face images allows client to support their specific use-cases with need of the face biometrics.

API Reference

The Digital Identity Service API reference is published here

Distribution package contents

You can find the distribution package in our CRM portal. It contains these files:

Your sales representative will provide you the credentials for the CRM login.
  • config – The configuration folder

    • application.yml – The application configuration file, see Application configuration

    • logback-spring.xml – The logging configuration file

  • doc – The documentation folder

    • Innovatrics_DOT_Digital_Identity_Service_1.2.1_Technical_Documentation.html – Technical documentation

    • Innovatrics_DOT_Digital_Identity_Service_1.2.1_Technical_Documentation.pdf – Technical documentation

    • swagger.json – Swagger API file

    • EULA.txt - The license agreement

  • docker – The Docker folder

    • Dockerfile – The text document that contains all the commands to assemble a Docker image, see Docker

    • entrypoint.sh – The entry point script

    • withCache

      • Dockerfile – The text document that contains all the commands to assemble a Docker image with both server and cache running in one container

      • entrypoint.sh – The entry point script

      • install_memcached.sh - The script to install memcached

  • libs – The libraries folder

    • libsam.so – The Innovatrics OCR library

    • libiface.so – The Innovatrics IFace library

    • solvers – The Innovatrics IFace library solvers

  • dot-digital-identity-service.jar – The executable JAR file, see How to run

  • Innovatrics_DOT_Digital_Identity_Service_1.2.1_postman_collection.json – Postman collection

Installation

System requirements

  • Ubuntu 18.04 (64-bit)

Steps

  1. Install the following packages:

    • OpenJDK Runtime Environment (JRE) (openjdk-11-jre)

    • userspace USB programming library (libusb-0.1)

    • GCC OpenMP (GOMP) support library (libgomp1)

    • Locales

    apt-get update
    apt-get install -y openjdk-11-jre libusb-0.1 libgomp1 locales
  2. Set the locale

    sed -i '/en_US.UTF-8/s/^# //g' /etc/locale.gen && locale-gen
    export LANG=en_US.UTF-8; export LANGUAGE=en_US:en; export LC_ALL=en_US.UTF-8
  3. Extract the Digital Identity Service distribution package to any folder.

  4. Link the application libraries:

    ldconfig /local/path/to/current/dir/libs
    Replace the path /local/path/to/current/dir in the command with your current path. Keep /libs as a suffix in the path.

Activate the DOT license

The activation of the DOT license depends on the type of your deployment.

If you perform serverless or Docker deployments, please contact your sales representative or sales@innovatrics.com to receive a license. Once you receive the license, please deploy it as described in step 5 below.

If you perform a bare metal installation, or use a fixed VM or AWS instance, perform the following steps:

  1. Run DOT Digital Identity Service to generate the Hardware ID necessary for the license.

    java -Dspring.config.additional-location=file:config/application.yml -Dlogging.config=file:config/logback-spring.xml -DLOGS_DIR=logs -Djna.library.path=libs/ -jar dot-digital-identity-service.jar

    Copy the Hardware ID, which you can find in the output. See the example below:

    Unable to init IFace. Hardware ID: xxxxxxxxxxxx
  2. Visit our CRM portal and go to Products > Digital Onboarding Toolkit > Licenses.

  3. Then, select Generate License and paste the Hardware ID.

    Generate license
  4. Confirm again with Generate License and download the license.

  5. Copy your license file iengine.lic for Innovatrics IFace SDK 4.15.0 into {DOT_DIGITAL_IDENTITY_SERVICE_DIR}/license/

How to run

As Digital Identity Service is a stand-alone Spring Boot application with an embedded servlet container, there is no need for deployment on a pre-installed web server.

Digital Identity Service needs a running memcached instance or cluster. You have to configure memcached via the externalized configuration first.

You can run the Digital Identity Service from the application folder:

java -Dspring.config.additional-location=file:config/application.yml -Dlogging.config=file:config/logback-spring.xml -DLOGS_DIR=logs -Djna.library.path=libs/ -jar dot-digital-identity-service.jar

Embedded Tomcat web server will be started and the application will be listening on the port 8080 (or another configured port).

Docker

For building a Docker image, you can use the Dockerfile and the entrypoint.sh script. A Dockerfile example and Entrypoint.sh script example can be also found in the Appendix.

Build the Docker image as follows:

cd docker
cp ../dot-digital-identity-service.jar .
cp ../libs/libsam.so.* .
cp ../libs/libiface.so.* .
cp -r ../libs/solvers/ ./solvers
docker build --build-arg JAR_FILE=dot-digital-identity-service.jar --build-arg SAM_OCR_LIB=libsam.so.* --build-arg IFACE_LIB=libiface.so.* -t dot-digital-identity-service .

Digital Identity Service needs a running memcached instance or cluster. You have to configure memcached via the externalized configuration first.

Run the container according to the instructions below:

docker run -v /local/path/to/license/dir/:/srv/dot-digital-identity-service/license -v /local/path/to/config/dir/:/srv/dot-digital-identity-service/config -v /local/path/to/logs/dir/:/srv/dot-digital-identity-service/logs -p 8080:8080 dot-digital-identity-service
Replace the path /local/path/to/license/dir/ in the command with your local path to the license directory.
Replace the path /local/path/to/config/dir/ in the command with your local path to the config directory (from the distribution package).
Important Replace the path /local/path/to/logs/dir/ in the command with your local path to the logs directory (you need to create the directory mounted to a persistent drive). The volume mount into the docker is mandatory, otherwise application does not start successfully.

Logging

Digital Identity Service logs to the console and writes the log file (dot-digital-identity-service.log) as well. The log file is located at a directory defined by the LOGS_DIR system property. Log files rotate when they reach 5 MB size and the maximum history is 5 files by default.

API Transaction Counter Log

The separate log file dot-digital-identity-service-transaction-counter.log is located at a directory defined by the LOGS_DIR system property. This log file contains information about counts of API calls (transactions). The same rolling policy is applied as for the application log, except the maximum history of this log file is 180 files.

Docker: Persisting log files in local filesystem

When you run Digital Identity Service as a Docker container, you may have access to log files even after the container doesn’t exist anymore. This can be achieved by using Docker volumes. To find out how to run a container, see Docker.

Monitoring

Information as build or license info can be accessed on /api/v1/info. Information about available endpoints can be viewed under /swagger-ui.html.

The health endpoint accessible under /api/v1/health provides information about the health of the application. This feature can be used by an external tool such as Spring Boot Admin, etc.

Application also supports exposing metrics in standardised prometheus format. These are accessible under /api/v1/prometheus. You can expose this endpoint in your configuration:

management:
  endpoints:
    web:
      exposure:
        include: health, info, prometheus

For more information, see Spring Boot documentation, section Production ready monitoring. Spring Boot Actuator Documentation also provides info about other monitoring endpoints that can be enabled.

Tracing

OpenTracing API with Jaeger implementation is used for tracing purposes. The Digital Identity Service tracing implementation supports SpanContext extraction from HTTP request using HTTP Headers format. For more information, see OpenTracing Specification. Tracing is disabled by default. To enable Jaeger tracing:

Set these application properties:

opentracing:
  jaeger:
    enabled: true
    udp-sender:
      host: jaegerhost
      port: portNumber

For more information about Jaeger configuration, see Jaeger Client Lib Docs.

Architecture

Digital Identity Service is a semi-stateful service. It is temporarily persisting intermediate results and images in an external cache. Thanks to this, the exposed API allows to flexibly use just the methods needed for a specific use case without the need to repeat expensive operations. Another advantage is that the user can provide the data when they are available without the need to cache them on the user’s side.

The Digital Identity Service can be horizontally scaled. Multiple instances of the service can share the same cache or a cache cluster.

Architecture diagram
Figure 1. Horizontal scaling of Digital Identity Service with a memcached cluster

The services of Digital Identity Service are better suited for processes that do not take long time. Anyway the cache can be configured to support various use cases and processes.

Cache

The Digital Identity Service currently supports Memcached as a cache implementation.

There are various tools for monitoring the performance of your Memcached server and we recommend to use one.

Memcached configuration

The cache is configurable via the externalized configuration.

It can be configured either with the AWS Elastic Cache or you can use a list of hosted memcached servers.

Efficient memory usage

For the optimal performance you have to configure the expiration of records according to the nature of the implemented process:

  • Short expiration time causes a smaller memory usage and a higher throughput of short requests.

  • Long expiration time allows a longer processing of cached records and causes higher memory requirements.

The memory consumption for longer processes can be lowered by cleaning records once they are not needed. The API provides delete methods for each resource.

The expiration of records can be configured independently for the onboarding API and for the face operations.

Table 1. Cache configuration properties

Property

Description

innovatrics.dot.dis.cache

  • customer-expiration

The time to persist all data created and used by Onboarding API in seconds.

Example value: 1800

  • face-expiration

The time to persist face records created and used by Face API in seconds.

Example value: 600

innovatrics.dot.dis.persistence.memcached

  • aws-elastic-cache-config-endpoint

The host and port of aws elastic cache config endpoint.

Format: host:port

  • servers

The list of host and port pairs to the memcached instances. Only used if aws elastic cache config endpoint is not configured.

Format: host1:port1 host2:port2

  • read-timeout

The memcached read timeout in milliseconds.

Example value: 2000

  • write-timeout

The memcached write timeout in milliseconds.

Example value: 2000

  • operation-timeout

The memcached operation timeout in milliseconds.

Example value: 5000

Authentication

The Digital Identity Service API is secured with an API Key authentication, therefore you will need to send an HTTP Authorization header with every request.

The header must contain a Bearer token, which is a UTF-8 Base64 encoded string that consists of two parts, delimited by a colon:

Table 2. Token description

Token part

Description

  • API Key

A unique identifier that you will receive along with your license

  • API Secret

A unique string that you will receive along with your license

The server will return a HTTP 403 Forbidden response for every request that either does not contain the Authorization header or if the contents of the header are invalid (e.g.: malformed Base64 or invalid API Key or Secret).

Some endpoints are not secured by design (such as /metrics, /health or /info) and do not require any authentication

Authorization header creation

The following is an example snippet of the structure of API key and secret in the license file:

{
  "contract": {
    "dot": {
      "authentication": {
        "apiKeyAndSecrets": [
          {
            "key": "some-api-key",
            "secret": "mb7DZQ6JwesRHkWPbjKVDgGHXxrAHFd6"
          }
        ]
      }
    },
    ...
  },
  ...
}

You will need to encode the key and secret parts into a valid UTF-8 Base64 string (those two parts, delimited by a colon), e.g.:

some-api-key:mb7DZQ6JwesRHkWPbjKVDgGHXxrAHFd6

You can do the encoding itself via the bash command below:

echo 'some-api-key:mb7DZQ6JwesRHkWPbjKVDgGHXxrAHFd6' | base64 -w 0

Once you encode the aforementioned token into Base64, each request must contain the Authorization header which consists of the Bearer keyword and the encoded key and secret:

Bearer c29tZS1hcGkta2V5Om1iN0RaUTZKd2VzUkhrV1BiaktWRGdHSFh4ckFIRmQ2

Image Data Downloader

The Digital Identity Service API supports 2 ways how to provide an image in its requests:

  • base64 encoded data

  • url to the remote image

Images provided are being downloaded by Image Data Downloader.

The connection timeout and the read timeout for the Image Data Downloader are configurable via properties.

Table 3. Image Data Downloader configuration properties

Property

Description

innovatrics.dot.dis.data-downloader

  • connection-timeout

The connection timeout for image data downloader in milliseconds.

Default value: 2000

  • read-timeout

The read timeout for image data downloader in milliseconds.

Default value: 30000

Logging Transactions via Countly

For billing purposes, you have to report all transactions performed by any running instance of the Digital Identity Service.

The Digital Identity Service can be configured to periodically publish metadata about executed transactions to Countly. You have to configure the URL to Countly to set up automatic reporting.

There are no sensitive details stored, only information about transaction count, outcome of operations and the quality of inputs. The collected statistics may be later used to improve the performance of the system in your environment.

Every data published to Countly is also being logged to a file named dot-digital-identity-service-countly-event.log. If you are unable to integrate with an external Countly server to setup automatic reporting, you can report transactions by sending the content of this file.

Table 4. Countly configuration properties

Property

Description

innovatrics.dot.dis.countly-connector

  • server-url

The URL to a Countly server.

If the property is not configured, transactions are not being automatically reported.

  • update-interval-seconds

The update interval in seconds for reporting transactions.

Default value: 60

Customer Onboarding

The Customer Onboarding API enables a fully digital process to remotely verify identity to enroll a new customer.

During the onboarding, a person registers with a company or government entity. They will provide their identity document, and one or more selfies to prove their identity.

With a digital onboarding process powered by Digital Identity Service, a company can easily and securely convert a person to a trusted customer.

Standard Onboarding Flow

The recommended customer onboarding process looks like this:

To use any part of the Customer Onboarding API you need to create a customer first. The customer will be persisted for a configurable amount of time (see the config section). Once created, you can perform additional actions while the record is persisted.

The data-gathering steps (2-4) can be performed in any order. The extracted data can be deleted or replaced by repeating the same action with different inputs.

The results of the get customer request (5) or inspection steps (6-7) depend on data previously gathered.

Once the onboarding is over you can delete the customer to reduce the memory needed. Deleting a customer will remove any related data such as selfies or document pages. Otherwise, the data will expire after a configured amount of time.

Actions for onboarding a customer have to be performed sequentially, parallel processing on the same customer is not allowed. If there are concurrent requests on any resource belonging to the same customer resource, only one of them will succeed and the rest will end with an error (409 Conflict). For example, it is not possible to upload the front and the back page of the document in parallel.

Create Customer

To create a customer, you have to make a POST /customers request.

The response will contain a link to the newly created customer resource as well as the ID of the customer.

Add Selfie

To provide a selfie for a customer you have to make a PUT /selfie request on the customer resource.

You have to provide a base64 encoded image or an URL to the input image. It is not allowed to provide both.

A successful response will contain the position of the detected face in the input image, the confidence, and a link to the newly created customer selfie resource. The response may contain a list of warnings as well. An unsuccessful response will contain the error code.

The position of the face is represented by the face rectangle.

The detection confidence contains a score from the interval <0.0,1.0>. Values near 1.0 indicate a high confidence a human face was detected.

There can be at most one selfie for a customer. You can replace the existing one by adding a new selfie.

Once the face is detected, you can:

Face Detection Configuration

The face detection on customer’s selfie is configurable. You can adjust the speed, accuracy, and other aspects according to your needs and available resources. You can find more details about image requirements, face detection speed-accuracy modes, and face size ratio, in the Face API section of this document.

Liveness Detection

Liveness detection allows you to verify that you are interacting with a live, physically present person. It can distinguish live faces from photos, videos, 2D/3D masks, and other attacks.

The Digital Identity Service offers different approaches to verify the liveness:

In general, the liveness detection consists of 3 following steps:

Create Liveness Detection

To create a liveness detection, you have to make a PUT /liveness request on the customer resource.

The response will contain a link to the newly created customer’s liveness resource.

Add Selfie to Liveness Detection

To Add a selfie, you have to make a POST /liveness/selfies request on the customer’s liveness resource.

If you want to use a selfie, that was already added as a customer’s selfie, you have to specify the reference to it in the payload.

The other option is to provide a new selfie for the liveness detection. In this case, you have to provide a base64 encoded image or an URL to the input image. It is not allowed to provide both.

For each selfie added to the liveness detection, you have to specify the assertion. The provided assertion will determine if and how the selfie will be used for the selected liveness method evaluation in the next step.

The successful response will be empty.

If the quality of the selfie does not fully match the requirements for evaluation, the response will contain a warning. If this happens, you can still use this selfie to evaluate the liveness, however, the result is not guaranteed to be reliable. If you do not want to proceed with this selfie, you have to delete the liveness resource and start again by creating a new one.

If the selfie was not accepted, the response will contain an error code.

You can add multiple selfies to one liveness detection.

The Digital Identity Service will try to detect a face on every selfie provided. The configuration of face detection on selfies is explained in this chapter.

Evaluate Liveness

To evaluate the liveness, you have to make a POST /liveness/evaluation request on the customer’s liveness resource.

You have to specify the type of liveness detection to be evaluated.

A successful response will contain a score from the interval <0.0,1.0>. Values near 1.0 indicate high confidence, that associated selfies contained a live person.

An unsuccessful response will contain an error code.

You can repeat the evaluation for different types of liveness on the same liveness resource. Only selfies with a relevant assertion will be used for a given type of liveness.

Passive Liveness Detection

The passive liveness detection is a process of determining whether the presented face is a real person without requiring the user to perform any additional actions.

It is recommended to perform this check on the customer`s selfie. You can add the existing customer’s selfie to the liveness detection by providing a reference to it.

To add a selfie for a passive liveness evaluation, you have to set the assertion to NONE. Only selfies with this assertion will be evaluated for passive liveness.

To evaluate the passive liveness you have to specify the type of liveness as PASSIVE_LIVENESS.

The passive liveness can be evaluated once at least a single selfie with the correct assertion was added. If there are multiple selfies with the corresponding assertion, the returned score will be the average of all of them.

Eye-gaze Liveness Detection

The eye-gaze liveness detection is the process of determining whether the presented faces belong to a real person, by requiring the user to follow an object displayed on the screen with their eyes.

This check is recommended for applications, where the security is in the first place and is recommended as an additional step after performing the passive liveness detection.

To implement the eye-gaze liveness detection you have to:

  1. generate object movement instructions randomly on your application server

  2. send these instructions to the client and ask the customer to follow the movement of the object with his eyes

  3. capture photos of the customer while he follows the object and add them to the liveness with a corresponding assertion

Selfies for eye-gaze liveness need to have one of the following assertion values: EYE_GAZE_TOP_LEFT, EYE_GAZE_TOP_RIGHT, EYE_GAZE_BOTTOM_LEFT, EYE_GAZE_BOTTOM_RIGHT

Each of these assertions corresponds to the position of the object at the moment the photo was taken.

Selfies with assertions needs to be provided sequentially in the order as they were captured. Parallel processing is not allowed.

The eye-gaze liveness can be evaluated only once the required number of selfies with relevant assertions was added.

The minimum number of selfies for eye-gaze liveness is configurable via a property.

Smile Liveness Detection

The smile liveness detection is the process of determining whether the presented faces belong to a real person, by requiring the user to change his expression.

To implement the smile liveness detection you have to:

  1. ask the customer to maintain a neutral expression and then to change it to smiling

  2. capture photos of the customer with both expressions and add them to the liveness with a corresponding assertion

Selfies with assertions need to be provided sequentially. Parallel processing is not allowed.

The smile liveness can be evaluated only once selfies with both SMILE and NEUTRAL assertions were added.

Customer Document Operations

The Onboarding API provides services to recognize and process customer’s photo identity documents. (Only identity documents containing a photo of the holder are usable for remote identity verification.)

The process starts with creating an identity document. At this point, you can provide information about the document’s type and/or edition. You can also specify what parts of the document you want to process.

The second step is to upload pictures of the documents’ pages. The system will try to detect and classify the document on the picture.

Once at least one page is successfully recognized, you can:

Supported Identity Documents

The Digital Identity Service can support identity documents of following types:

  • Passports

  • Identity cards

  • Driving licenses

  • Foreigner permanent residence cards

  • and other cards of similar format containing a photo of holder

The support for document recognition may be in two levels:

Level 1 support

The Level 1 support includes all documents that are compliant with the ICAO machine-readable travel document specification.

The Digital Identity Service can process the document portrait and parse data from the machine-readable zone of documents with this level of support.

Level 2 support

For Level 2 support, the Digital Identity Service needs to be trained to support each individual document type and its edition.

Once the document is supported, the Digital Identity Service can process any data available on it.

You can find the list of documents with Level 2 support via the get metadata endpoint.

In case an ID document type required does not have Level 2 support, it is possible to contact Innovatrics to request support of such document type in a future version of the Digital Identity Service.

Get Metadata for documents with the Level 2 support

To get the full list of documents with the Level 2 support you have to make a GET /metadata request.

The response contains a list of documents supported by the current version of the Digital Identity Service and the metadata for each document.

The metadata for an individual document contains a list of its pages. For each page, there is a list of text fields, that the Digital Identity Service was trained to OCR.

For each text field, there is information if the field’s value is being returned as found on the document or if it is being normalized and returned in a standard format.

If present on the document, there is also the original label for each text field.

Document Classification

The amount of data that the Digital Identity Service can extract from an identity document depends on how precisely it can classify this document.

There are 3 levels of classification:

The Digital Identity Service tries to classify the document up to the level that allows the processing of all requested document sources:

  1. It will try to fully classify the document if the processing of visual zone or barcodes was requested.

  2. Otherwise, it will only try to recognize the travel document type of the document.

  3. If the document was not at least partially classified, it will be processed as an unknown document.

The classification of a document can be affected by classification advice that can be optionally provided in the create document request payload.

It can be also affected by optional advice on the type of page in the add document page request payload.

Full classification

A full classification means the Digital Identity Service knows the type of the document, its issuing country, the exact edition, and the type of the travel document if the document is compliant with travel document specifications.

Only documents that have Level 2 support can be fully classified.

Any document source on a fully classified document can be processed. That means the Digital Identity Service can:

  • ocr textual data from the visual zone

  • parse data from the machine-readable zone

  • decode data from barcodes

  • extract biometric information from the document portrait

  • check input for tampering by inspecting the color profile of the image

  • identify image fields: signature, fingerprint, ghost portrait and document portrait

Partial classification

A partial classification means the Digital Identity Service knows the type of the travel document.

With a partially classified document, only the machine-readable zone and the document portrait sources can be processed. That means the Digital Identity Service can:

  • parse data from the machine-readable zone

  • extract biometric information from the document portrait

Partial classification is possible for any document with Level 1 support.

A document can be partially classified only after a page containing a machine-readable zone is provided. That means:

  • TD1 document can be partially classified after a back page is provided. If the front page was provided first, it will stay unrecognized till the back page is added.

  • TD2 and TD3 documents can be partially classified after a front page is provided

Document not recognized

If the Digital Identity Service was unable to recognize the document’s exact edition nor its travel document type, then the document will be processed as an unknown document.

With an unknown document, the Digital Identity Service can only process the document portrait source. If a portrait is present on the provided page, the Digital Identity Service can:

  • extract biometric information from the document portrait

The system only keeps the last provided page for an unknown document. If there are multiple images provided and the document is still unknown, all previous pages are replaced with the last one.

Classification of an additional page

Once the document is at least partially classified, any page added later has to match the existing classification.

  • That means if the document is fully classified, then it will only accept pages from the same document edition.

  • If the document is partially classified, then it will accept pages from documents with the same travel document type.

  • If the document is not recognized, it will accept pages of any type.

It is possible to increase the level of classification of a document with an additional page. For example, the exact edition of a document that is only partially classified as a travel document of TD1 type can be later specified by recognizing it from an additional page. The recognized edition has to be compliant with the already recognized type of travel document. The classification level will move from partial classification to full classification.

If the document was classified incorrectly, you have to delete the whole document and start again. You can improve the classification by providing classification advice and/or by providing images of better quality.

Create Document

To create an identity document for a customer you have to make a PUT /document request on the customer resource.

You can improve the performance of the document processing by providing classification advice and/or specifying data sources on the document that you want to process.

The response will contain a link to the newly created customer document resource.

There can be at most one document for a customer. You can replace the existing one by creating a new document for the customer.

Classification Advice

If you know upfront what type of document will be uploaded, you can improve the performance of the classification by providing classification advice.

With the classification advice, you can influence how the document will be recognized. You can restrict potential candidates by specifying allowed countries, document types, editions, and/or travel document types.

If no advice is provided, the system will perform the classification considering all supported document types.

Document Sources

You can improve the performance of the document processing by specifying what parts of the document need to be processed.

You can provide a list of document sources that need to be processed. If the list of sources is not provided in the request, or if it is empty, then the Digital Identity Service will try to process all of them.

Table 5. Supported document sources

Document Source

Description

Requirements

visual zone

  • read data from text fields

  • crop image fields: signature, ghost-portrait, fingerprint

document page needs to be fully recognized

machine-readable zone

  • parse data from machine-readable zone

the type of machine-readable travel document needs to be recognized

document portrait

  • extract biometric data from document portrait

document portrait needs to be present on provided page

barcode

  • extract data encoded in barcodes

document page needs to be fully recognized

Add Document Page

To add a page to the identity document for a customer you have to make a PUT /pages request on the customer’s document resource.

You can improve the performance of the page’s processing by specifying whether it is a front or a back page in the classification advice.

The optional classification advice in the add document page request can specify only the type of page. To provide advice on the type of document, you have to use the classification advice in the create document request.

A successful response will contain info about the classified document type and the recognized type of page. It will also contain the position of the detected document in the input image, the confidence, and a link to the newly created document page resource.

The response may contain a list of warnings.

An unsuccessful response will contain the error code.

When a page for a document is provided, the Digital Identity Service will try to recognize the type of page and the type of document. This process is called classification and is described in the chapter Document Classification.

Image requirements

Ideally, the photo of identity document should be created with Innovatrics’ auto-capture components, whether in mobile libraries or browser-based. These components ensure the quality requirements mentioned below:

  • The supported image formats are JPEG, PNG or GIF

  • The document image must be large enough — when the document card is normalized, the text height must be at least 32 px (document card height is approximately 1000 px)

  • The document card edges must be clearly visible and be placed at least 10 px inside the image area

  • The image must be sharp enough for the human eye to recognize the text

  • The image should not contain objects or background with visible edges. (example below) This can confuse the process of detecting card on image

EdgesDemo
Figure 2. Examples of invalid and valid images

Check Document Page Quality

To check the quality of a provided image for a document page you have to make a Get /quality request on the document page resource.

The response contains details about the brightness, sharpness, and the presence of hotspots on the original image.

The response also contains a list of found issues and a list of warnings.

Table 6. Quality check examples
Quality check resultInput image

OK

Ok

WARNING: DOCUMENT_CLOSE_TO_IMAGE_BORDER

The distance of at least one detected corner point from the nearest image border is less than 2% of the image width or height.

Document close to image borders

ISSUE: BRIGHTNESS_LOW

The brightness score is below 0.25

Low brightness

ISSUE: BRIGHTNESS_HIGH

The brightness score is over 0.9

High brightness

ISSUE: SHARPNESS_LOW

The sharpness score is bellow 0.85

Low sharpness

ISSUE: HOTSPOTS_SCORE_HIGH

The hotsposts score is over 0.008

Hotspots

ISSUE: DOCUMENT_OUT_OF_IMAGE

At least one corner point of the document was detected outside the image area.

Document out of image

ISSUE: DOCUMENT_SMALL

The width of the detected document should be over 450px and the height over (450px / aspect ratio). If any detected edge of the document does not meet these requirements, the document is considered to be too small.

Small document

Get Document Page Image

To get the normalized image for a document page you have to make a GET / request on the document page resource.

You can request an image to be returned in a specific size by providing optional query parameters width and/or height.

The Response contains a base64 encoded image with a document page in the JPG format. The compression quality of returned images can be configured via the property.

Normalized page
Figure 3. Normalized document page

Get Document Image Fields

The Customer Onboarding API provides methods to get image fields from recognized document pages.

Supported image fields are:

If the customers' document does not contain a requested image field or if the page with the field was not provided or it was not recognized, the service will return a not found error with 404 error code.

The successful response contains a base64 encoded image with a document page in the JPG format. The compression quality of returned images can be configured via the property.

You can request any image field to be returned in a specific size by providing optional query parameters width and/or height.

Get Document Portrait

To get an image with a document portrait you have to make a GET /portrait request on the document resource.

The successful Response contains a base64 encoded image with a document portrait in the JPG format.

Document portrait
Figure 4. Document portrait

The document portrait is available if it was present on a previously uploaded document page, even if the page was not recognized.

Get Document Ghost Portrait

To get an image with a ghost portrait you have to make a GET /ghost-portrait request on the document resource.

The successful Response contains a base64 encoded cropped ghost portrait image in the JPG format.

The ghost portrait is only available if the visual zone source processing was requested when the document resource was created. The ghost portrait has to be present on a previously uploaded and recognized document page as well.

Get Document Signature

To get an image with a signature you have to make a GET /signature request on the document resource.

The successful Response contains a base64 encoded cropped signature image in the JPG format.

Document signature
Figure 5. Document signature

The signature image is only available if the visual zone source processing was requested when the document resource was created. The signature has to be present on a previously uploaded and recognized document page as well.

Get Document Fingerprint

To get an image with a fingerprint you have to make a GET /fingerprint request on the document resource.

The successful Response contains a base64 encoded cropped fingerprint image in the JPG format.

The fingerprint image is only available if the visual zone source processing was requested when the document resource was created. The fingerprint has to be present on a previously uploaded and recognized document page as well.

Inspect Document

The Digital Identity Service API provides an endpoint to check consistency of data of the submitted document. This can be useful for authenticity and data manipulation checks.

To perform this inspection, you will need to make a POST request on the /document/inspect endpoint.

Based on the requested sources and provided data, the response contains results of the following checks:

For a detailed overview of the response itself, please refer to the OpenAPI specification of this endpoint.

Expiration check

If the document contains an expiration date, the system will check if the document is expired or not.

MRZ Validity check

If the MRZ was processed, the system checks if it conforms to the ICAO specification.

Portrait inspection

If the document portrait was processed, the estimated age and gender are compared with corresponding values from other sources. The consistency of estimated age is evaluated only if the date of issue of the document is present.

Visual Zone inspection

The result of the the inspection includes a list of fields that are inconsistent, a list of fields with low OCR confidence and a median of all OCR confidences for the available fields.

The threshold for low OCR is configurable via a property.

Color profile change detection

The color profile change detection checks if the colors on the detected document corresponds to the trained model for the classified document edition.

This check is available only for documents with Level 2 support. The document also needs to be fully classified.

Table 7. Color profile change detection examples
color profile change detectedInput image

true

Color profile change detected

false

Genuine image

Screenshot detection

The screenshot detection checks if the provided image is a genuine photo of a document or if it was taken from a screen of another device.

Table 8. Display attack detection examples
looks like a screenshotInput image

true

A display attack was detected.

Display attack detected

false

No display attack was detected.

Genuine image

Inspect Customer

To check the consistency of gathered biometric data about the customer, you have to make a POST /inspect request on the customer resource.

The response contains any biometric data extracted from the customer’s selfie and a comparison of this data with other available customer data.

The response provides a comprehensive overview of customer biometric data consistency in one single place, thus providing an opportunity to detect inconsistencies and to assess credibility of provided customer selfies and selected data from the document.

Digital Identity Service evaluates consistency of customer’s selfie with liveness selfies, document portrait, and/or text data read from identity document.

Based on the provided sources, the response provides the following information:

Biometric face aspects estimations

Age and gender are estimated from the customer’s selfie.

Face similarities

Customer selfie face is checked for similarity with other customer faces provided - identity document portrait face and faces on liveness selfies. Faces are considered similar when the respective face similarity threshold is reached. Face similarity threshold for selfie comparison with liveness selfies is configurable via property. Face similarity threshold for selfie comparison with document portrait is configurable via property.

Age differences

Comparison of age estimated from customer selfie with age from document portrait and age calculated from document’s text fields.

The age comparison with document portrait is performed only if the date of issue of the document is present.

Gender consistencies

Indication whether the gender evaluated from the customer’s selfie face matches the gender from other sources.

Face mask detection

Reports whether a mask was detected on the customer’s selfie.

The person on the selfie is considered wearing a face mask, when the face mask detection score reaches a threshold configurable via property.

Get Customer Data

To get all gathered data about a customer you have to make a GET / request on the customer resource.

The response contains data extracted from the provided selfie and/or from provided document pages.

Attributes in the response contain values per source from which the value was extracted. Values may be extracted from: visual zone, mrz, selfie, document portrait, barcodes.

If a document was provided, the response contains links to resources of every present document page and image. You can use them to get images of normalized pages and/or image fields

Face biometrics

The Face API provides a service to detect face in an image. Once detected, the face will be persisted for a configurable amount of time (see the config section). You can use the face resource to execute additional actions while the record is persisted.

It also offers a method to evaluate the quality of a detected face and the face image. You can use this method in order to verify if the detected face matches standards for a specific use case and if a result of an additional action can be trusted.

There are additional actions that can be performed with a detected face while it is being held in cache:

Detect Face

To detect a face you have to make a POST /faces request.

You have to provide a base64 encoded image or an url to the input image. It is not allowed to provide both.

The successful response will contain the position of the detected face in the input image, the confidence and a link to the newly created face resource. The response may contain a list of warnings as well. The unsuccessful response will contain the error code.

The position of the face is represented by the face rectangle.

The detection confidence contains a score from the interval <0.0,1.0>. Values near 1.0 indicates a high confidence a human face was detected. Some additional actions may be performed only on faces detected with a confidence above a certain threshold. You can find the specific limits in the quality section.

Image requirements

  • The supported image formats are JPEG, PNG or GIF

Detection mode

Optionally you can specify the detection mode: FREE or STRICT. The Strict model is being used by default.

  • STRICT mode will return an error if multiple faces are detected.

  • FREE mode will return the largest face and a warning if multiple faces are detected. The performance of the detection in the FREE mode is affected by the max detection count property.

    • If the max detection count is lower than the actual number of faces on the image, then it is not guaranted that the biggest face will be detected and returned.

    • If the max detection count is much higher than the number of faces on the single image inputs, then the detection runs slower than needed.

Face size ratio

The Face size ratio is a ratio between the face size and the shorter side of an image.

The service detects only faces with a face size ratio within a certain range that is configurable via min and max properties.

Optionally you can override the configuration by specifying a custom face size ratio in the request.

Min face size ratio restrictions

The size of detectable faces depends on the input image and the configured face detection speed accuracy mode.

The allowed min face size ratio is restricted based on the size of the input image. If the requested min face ratio is too small for the input image, the detection request will end up with an error: FACE_SIZE_MEMORY_LIMIT.

Table 9. Min valid face size calculation per detection mode
Face detection modeMin valid face size ratio calculation

fast

12 / "ShorterSide"

balanced,
accurate

max {

(3 / "ShorterSide"),
(10 / "FD_MAX_IMAGE_SIZE" * "LongerSide" / "ShorterSide")

}

ShorterSide and LongerSide values are in pixels. Big input images will be shrunk before processing so the longer side is at most 3000px. If the image needs to be shrunk, you have to use the resized lengths of longer and shorter sides to calculate the min valid face size ratio.

FD_MAX_IMAGE_SIZE is configurable via parameter.

Face detection speed accuracy mode

The face detection speed accuracy mode represents a trade-off between face and facial features detection speed and accuracy. By default the face detection runs in the accurate mode. If you want to increase the speed of the detection, you have to change the detection mode via the face detection speed accuracy mode property.

Supported modes are:

  • fast - some faces that are partially occluded faces or faces with sunglasses may be missed. Also faces printed on ID cards may not be detected. However the speed performance of the face detection is much better as when other modes are used. It is compatible with DOT Mobile Kits.

  • balanced - the performance of the face detection is somewhere in between of accurate and fast modes.

  • accurate - partially occluded, blurry, profile faces or faces with sunglasses are detected. Speed of this face detection on CPU is the slowest comparing to other modes.

Check Face Quality

To find out if a face matches ICAO specifications or if it is suitable for additional processing you have to check its quality.

To get an info about the quality you have to make a GET /quality request on the detected face.

The response contains information about face expression, head pose and quality attributes of the image. Each attribute contains an actual score and a flag indicating if the score is reliable.

For each use case you have to check if preconditions for each relevant attribute are met and if their scores are from requested range.

ICAO conditions

Table 10. ICAO conditions

Attribute

Condition

face detection confidence

>= 0.53

yaw angle

<-10.0; 10.0>

pitch angle

<-10.0; 10.0>

roll angle

<-10.0; 10.0>

sharpness

<0.5; 1.0>

brightness

<0.25; 0.75>

contrast

<0.25; 0.75>

unique intensity levels

<0.5; 1.0>

shadow

<0.49; 1.0>

nose shadow

<0.496; 1.0>

specularity

<0.495; 1.0>

heavy frame

<0.0; 0.515>

mouth

<0.5; 1.0>

background uniformity

<0.3; 1.0>

right eye

<0.5; 1.0>

left eye

<0.5; 1.0>

red right eye

<0.0; 0.5>

red left eye

<0.0; 0.5>

eye gaze

<0.48; 1.0>

Liveness preconditions

Table 11. Liveness preconditions

Attribute

Condition

face detection confidence

>= 0.55

face size

>= 60px

yaw angle

<-20.0; 20.0>

pitch angle

<-20.0; 20.0>

brightness

<0.11; 0.75>

contrast

<0.25; 0.8>

unique intensity levels

<0.525; 1.0>

Mask detection preconditions

Table 12. Mask detection preconditions

Attribute

Condition

face detection confidence

>= 0.53

eye distance

<12; 100 000>

Glasses detection preconditions

Table 13. Glasses detection preconditions

Attribute

Condition

face detection confidence

>= 0.53

yaw angle

<-40.0; 40.0>

pitch angle

<-40.0; 40.0>

Age & Gender preconditions

Table 14. Age & Gender preconditions

Attribute

Condition

face detection confidence

>= 0.06

face size

>= 30px

yaw angle

<-20.0; 20.0>

pitch angle

<-15.0; 15.0>

Face Features

Face API provides operations to get features of the detected face.

Age and Gender

To get age and gender you have to make a GET /aspects request on the detected face.

The response contains an estimated age and a gender score from the interval <0.0,1.0>. Values near 0.0 indicates 'male', values near 1.0 indicates 'female'.

Mask

To check for the presence of a face mask you have to make a GET /face-mask request on the detected face.

The response contains a score from the interval <0.0,1.0>. Values near 1.0 indicate the presence of a mask.

The mask detection result is reliable only if the original image matches mask detection preconditions.

The mask detection only works when the face detection speed accuracy mode is set to balanced or accurate.

Glasses

To check for the presence of glasses mask you have to make a GET /glasses request on the detected face.

The response contains a score from the interval <0.0,1.0>. Values near 1.0 indicate the presence of glasses. The resposne containes additional scores for the presence of tinted glasses and glasses with a heavy frame.

The glasses detection result is reliable only if the original image matches glasses detection preconditions.

Face Crop

To get a face crop image you have to make a GET /crop request on the detected face.

The Response contains a base64 encoded image with a cropped face in the JPG format. The compression quality of returned images can be configured via the property.

The Service allows customizing width and height of the returned image via corresponding optional parameters.

Face Crop

Configure Crop Method

Two cropping methods defined in ISO/IEC 19794-5 standard are supported: FULL FRONTAL and TOKEN FRONTAL. By default the FULL FRONTAL is being used. It can be changed via the crop method property.

Crop without Background

To get a face crop with removed background you have to make a GET /crop/remove-background request on the detected face.

The Response contains a base64 encoded image in the PNG format.

The Service allows customizing width and height of the returned image via corresponding optional parameters.

Configure Segmentation

The segmentation can be fine-tuned by the segmentation threshold parameter. The segmentation threshold is in range <-10000, 10000>. It’s quantile-normalized and 0 represents equal error rate (EER). Higher segmentation threshold means that result image will contain more foreground. Lower segmentation threshold means that result image will contain more background.

Configure Returned Image Type

The type of returned image is determined based on the Segmentation Image Type property. Supported types:

  • mask - The segmentation mask only (single-channel)

  • masked - The three-channel image with applied segmentation. The masked areas are filled with the color defined by the background color property.

  • masked_alpha. - The four-channel image with applied segmentation. The masked areas are marked as transparent in the alpha channel.

Table 15. Segmentation Image Type Examples
originalcroppedmaskmaskedmasked_alpha

Original

Cropped

Mask

Masked

Masked Alpha

segmentation matting type: global
segmentation threshold: 0
segmentation matting possible threshold: 0
segmentation matting sure threshold: 500
background color: FFFFFF

Configure Background Color

When the image type is set to masked, it is possible to define the background color. Valid value is hexadecimal code string e.g. RRGGBB.

Table 16. Background Color Examples
background color: white FFFFFFbackground color: red FF0000

Masked White

Masked Red

segmentation type: masked
segmentation matting type: global
segmentation threshold: 0
segmentation matting possible threshold: 0
segmentation matting sure threshold: 500

Configure Segmentation Matting

To soften mask edges after segmentation you have to enable the global matting via the Segmentation Matting Type property.

You can fine tune softening mask edges by two thresholds: the Segmentation Matting Possible Threshold and the Segmentation Matting Sure Threshold.

  • <-10000, POSSIBLE_THRESHOLD> - The background for sure, the matting doesn’t influence this range.

  • <POSSIBLE_THRESHOLD, SURE_THRESHOLD> - The unsure range, the matting decides what is the foreground and what is the background

  • <SURE_THRESHOLD, 10000> - The foreground for sure, the matting doesn’t influence this range.

Table 17. Segmentation Matting Type Examples
segmentation matting type: globalsegmentation matting type: off

Masked White

Masked White

segmentation type: masked
segmentation threshold: 0
segmentation matting possible threshold: 0
segmentation matting sure threshold: 500
background color: FFFFFF

Crop Coordinates

To get coordinates of a face crop within the original input image you have to make a GET /crop/coordinates request on the detected face.

The response contains coordinates of 4 corner points and the information whether the crop is fully present within the input image.

Crop Coordinates
Figure 6. Illustration of crop coordinates

Create Face Template

To create a face template you have to make a GET /template request on the detected face.

The returned template can be used as a reference in the face verification.

Template extraction mode

The extraction mode represents a trade-off between face template creation speed and face template quality. By default the face template extraction runs in the accurate mode. If you want to increase the speed of the extraction, you have to change the extraction mode via the extraction speed accuracy mode property.

Supported modes are:

  • fast - produces face templates suitable for verification of fairly good accuracy are created when fast mode is used. The performance of face template creation is very fast. It is compatible with DOT Mobile Kits.

  • balanced - produces face templates suitable for verification/identification of high accuracy. The performance of the face template creation is somewhere in between of accurate and fast modes.

  • accurate - produces face templates suitable for verification/identification of very high accuracy. However the performance of the face template creation is not as good as when balanced or fast mode is used.

Match Face Against Reference

To verify the similarity between two faces or to match a face to a template you have to make a POST /similarity request on the detected face.

You have to provide a template or a face to be used as a reference. It is not allowed to provide both.

Face as a reference

Any face can be used as a reference while it is persisted in the cache. It is not possible to use a face after it expired. You can find the face identifier in the face resource url.

Reference template

To match a face with a face template, you have to provide the base64 encoded template. The template has to be compatible with the server’s configuration and supported by server’s version of the IFace.

If the provided template is not supported by the server’s version of the IFace, the error response with a code UNSUPPORTED_VERSION_TEMPLATE will be returned.

If the provided template was created with a different extraction speed accuracy mode, the error response with a code INCOMPATIBLE_TEMPLATE will be returned.

If the provided template is corrupted, the error response with a code CORRUPTED_TEMPLATE will be returned.

Application configuration

Digital Identity Service is configurable via YAML file under the config folder:

config/application.yml
Table 18. Digital Identity Service configuration properties

Property

Description

innovatrics.dot.dis

  • jpg-compression-quality

The compression quality of images returned in JPG format.

Default value: 0.9

innovatrics.dot.dis.iface

  • license.filepath

Innovatrics IFace license file path.

Default value: ../license/iengine.lic

  • solvers.filepath

Innovatrics IFace solvers file path.

Default value: ../solvers

  • crop-method

Face cropping method according to ISO/IEC 19794-5 standard.

Supported methods: FULL_FRONTAL and TOKEN_FRONTAL

  • face-template.extraction-speed-accuracy-mode

The face template extraction speed accuracy mode.

Supported modes: fast, balanced and accurate.

innovatrics.dot.dis.iface.face-detection

  • face-size-ratio.min

The minimal face size ratio of faces detected to the shorter side of an image. The application will recognize a face in the image only if the face size ratio >= than this value.

Default value: 0.05

  • face-size-ratio.max

The maximal face size ratio of faces detected to the shorter side of an image. The application will recognize a face in the image only if the face size ratio <= than this value.

Default value: 0.35

  • confidence-threshold

The face detection confidence threshold. Faces with a confidence score lower that this value will be ignored.

The supported interval is [0, 10000].

  • speed-accuracy-mode

The face template extraction speed accuracy mode.

Supported modes: fast, balanced and accurate.

  • max-detection-count

The max number of faces to detect in a single image when the mode is FREE.

Default value: 2

Min value: 2

See more in Detection mode.

  • max-image-size

The parameter defines maximal image size of image entering to internal solver in balanced and accurate detection mode.

It affects the memory requirements. When set to a higher number, the face detection consumes more memory.

The value of this param affects the limit for minFaceSize. If you need to set the minFaceSize to a smaller value to detect smaller faces then you have to set this parameter to a higher value.

Default value: 1200

innovatrics.dot.dis.iface.background-removal

  • segmentation-image-type

The parameter determines type of returned image. Valid values are mask, masked, masked_alpha.

  • segmentation-matting-type

The parameter defining type of matting used after head shoulder segmentation. Valid values are off, global.

  • segmentation-threshold

The parameter defining threshold for segmentation mask. The parameter should be in range <-10000, 10000>.

  • segmentation-matting-possible-threshold

The parameter defining threshold for a possible foreground for generating trimap for matting. The parameter should be in range <-10000, 10000>.

  • segmentation-matting-sure-threshold

The parameter defining threshold for a sure foreground for generating trimap for matting. The parameter should be in range <-10000, 10000>.

  • background-color

The parameter defining color which is used to fill in parts of cropped image that fall outside the original source image boundaries. Valid value is hexadecimal code string e.g. RRGGBB.

innovatrics.dot.dis.customer.eye-gaze-liveness

  • min-valid-selfies-count

The minimal selfie count required for eye gaze liveness.

Acceptable values: 4, 5, 6, 7

innovatrics.dot.dis.customer.selfie

  • face-size-ratio.min

The minimal face size ratio of faces detected in customer’s selfies. The application will recognize a face in the image only if the face size ratio >= than this value.

Default value: 0.1

  • face-size-ratio.max

The maximal face size ratio of faces detected in customer’s selfies. The application will recognize a face in the image only if the face size ratio <= than this value.

Default value: 0.4

innovatrics.dot.dis.customer.document.portrait

  • cropped-portrait-face-size-ratio.min

The minimal face size ratio of faces detected in customer’s document portrait of classified documents.

The application will recognize a face in the image only if the face size ratio >= than this value.

Default value: 0.14

  • cropped-portrait-face-size-ratio.max

The maximal face size ratio of faces detected in customer’s document portrait of classified documents. The application will recognize a face in the image only if the face size ratio <= than this value.

Default value: 0.4

  • non-cropped-portrait-face-size-ratio.min

The minimal face size ratio of faces detected in pages of unknown documents. The application will recognize a face in the image only if the face size ratio >= than this value.

Default value: 0.05

  • non-cropped-portrait-face-size-ratio.max

The maximal face size ratio of faces detected in pages of unknown documents. The application will recognize a face in the image only if the face size ratio <= than this value.

Default value: 0.25

innovatrics.dot.dis.customer.document.inspection

  • ocr-text-field-threshold

The ocr text field confidence threshold.

Text fields with a ocr confidence lower than this value will be listed in the inspection of the vizual zone.

Default value: 0.92

  • color-profile-change-detection-threshold

The color profile change detection threshold. Document pages with a score lower than this value will be evaluated as tampered.

The supported interval is [0.0, 1.0].

Default value: 0.4

  • screenshot-detection-threshold

The screenshot detection threshold. Document pages with a score lower than this value will be evaluated as display spoofs.

The supported interval is [0.0, 1.0].

Default value: 0.80

innovatrics.dot.dis.customer.inspection

  • face-mask-threshold

The face mask detection threshold.

If the mask detection score on a customer selfie is above this value, then the mask is considered to be present

The supported interval is [0.0, 1.0].

Default value: 0.4975

  • selfie-similarity-with-document-portrait-threshold

Customer selfie similarity with document portrait threshold.

Customer selfie and face detected on document portrait are evaluated as similar if their similarity confidence is above this value.

The supported interval is [0.0, 1.0].

Default value: 0.35

  • selfie-similarity-with-liveness-selfies-threshold

Customer selfie similarity with liveness selfies threshold.

Customer selfie and selfies added to liveness are evaluated as similar if their similarity confidence is above this value. If there are multiple liveness selfies, then the average confidence is used for the evaluation.

The supported interval is [0.0, 1.0].

Default value: 0.50

Appendix

Changelog

1.2.1 - 2022-05-27

  • Changed threshold for document looks like screenshot detection from 0.83 to 0.80

1.2.0 - 2022-05-27

  • Fixes and changed threshold for document looks like screenshot detection from 0.85 to 0.83

1.1.1 - 2022-05-19

  • Internal improvements

1.1.0 - 2022-05-12

  • Introduced Smile Liveness evaluation

  • Authentication mechanism changes

  • Other internal improvements

1.0.0 - 2022-04-19

  • Initial release

Digital Identity Service Dockerfile example

FROM ubuntu:18.04

WORKDIR /srv/dot-digital-identity-service

ARG JAR_FILE
ARG SAM_OCR_LIB
ARG IFACE_LIB

COPY ${JAR_FILE} ./app.jar
COPY ${SAM_OCR_LIB} ./libs/
COPY ${IFACE_LIB} ./libs/
COPY solvers/* ./libs/solvers/
COPY entrypoint.sh /usr/local/bin/

RUN set -ex \
  && apt-get update \
  && apt-get install -y openjdk-11-jre curl locales libusb-0.1 libgomp1 \
  && touch *.jar \
  && chmod 500 /usr/local/bin/entrypoint.sh \
  && ldconfig /srv/dot-digital-identity-service/libs/

ENV JAVA_OPTS=''
ENV LOGS_DIR=/srv/dot-digital-identity-service/logs

# Set the locale
RUN sed -i '/en_US.UTF-8/s/^# //g' /etc/locale.gen && \
    locale-gen
ENV LANG en_US.UTF-8
ENV LANGUAGE en_US:en
ENV LC_ALL en_US.UTF-8

CMD ["sh", "-c", "entrypoint.sh"]

Entrypoint.sh script example

#!/bin/sh
set -e

exec sh -c "java $JAVA_OPTS -Dspring.config.additional-location=file:config/application.yml -Dlogging.config=file:config/logback-spring.xml -jar app.jar"