Passive Liveness Check

Passive liveness check is a process of determining whether the presented face is a real person without requiring the user to perform any additional actions (unlike active liveness check).

This check is recommended for applications, where the user experience an seamless app flow is in the first place.

Mobile app libraries provide the passive liveness check in several ways. The passive liveness can be obtained from the quality attributes returned by Face Capture UI component.

Another way to get passive liveness in a mobile app is to run the face detector on an image of a face.

Core server can provide passive liveness check.

DOT passive liveness check achieved iBeta Level 2 PAD accreditation in accordance with the ISO 30107-03 PAD standard. See the confirmation letter. More on the test specification.

Passive Liveness and Photo Capture Method

It is important, that in the onboarding process is no possibility for the user to upload a photo himself. It has to be strictly enforced, that the user takes the selfie only using DOT Face Auto Capture component. Being able to upload a selfie photo allows the user to do manipulations, that cannot be detected.

Passive Liveness steps

In order to evaluate the passive liveness, following steps must be performed:

  • Face detection - find position of the face in the image
  • Passive liveness evaluation - calculates the passive liveness score and whether evaluation conditions were met. If conditions were not met, the result should taken with consideration.

Face detection

The first step of performing passive liveness check is face detection. This is an important step, because there may be no face or multiple faces present in the picture. Once a face is detected it can be used to evaluate the passive liveness. There are various face detection modes available, fast mode provides lower latency, in accurate mode detection is more precise. Mobile devices only support fast mode.

Passive liveness evaluation

A facial image with sufficient background should be submitted for evaluation. Minimum requirements for the image are:

  • image size at least 600x600px
  • distance between the eyes at least 120px
  • shorter side of the image should be at least 4 times the distance between the eyes in px
  • face should be present near the center of the image
  • not too strong backlight or sidelight
  • no overexposed or underexposed images
  • ICAO attributes are recommended to be compliant with table below
  • image should not be cropped or compressed between the capture and processing step
AttributeMinMax
BRIGHTNESS-78005000
CONTRAST-50006000
SHARPNESS-400010000
UNIQUE_INTENSITY_LEVELS50010000
PITCH_ANGLE-1515
YAW_ANGLE-2020

PassiveLivenessQualityProvider used in mobile components ensures all these conditions were met during capture.

Presentation attack detection

Our algorithm has been trained to detect real faces and also various kinds of spoof attacks. These include:

  • Faces displayed on electronic screen
  • Printed faces
  • 2D masks
  • 3D masks

We understand that new attacks might emerge, and we regularly retrain the models to incorporate new attack vectors. It is also important that our customers keep components up to date as we release them.

Passive liveness threshold

The final decision if the face is real or a spoof should be determined by the passive liveness score and the threshold. If the score is above the threshold, this can be interpreted as accepted. If the score is below the threshold, it is rejected.

Thresholds for Core Server 6.17.0 and above

FAR [%]FRR [%]Threshold
21.2686.54
11.8788.08
0.63.9188.92
0.27.2890.73
0.111.291.17

In the Core Server version 6.17.0, we recommend following thresholds based on the use case:

  • 88 Optimized for user convenienece
  • 89 Standard setting
  • 90.5 To ensure high security

Thresholds for Core Server 6.15.0 and 6.16.0

FAR [%]FRR [%]Threshold
21.3390.06
1.31.8791.13
12.5491.56
0.53.9592.62
0.28.4193.53

In the Core Server version 6.15.0, we recommend following thresholds based on the use case:

  • 90 Optimized for user convenienece
  • 91 Standard setting
  • 92.5 To ensure high security

Thresholds for Core Server 6.12.0, 6.13.0 and 6.14.0

FAR [%]FRR [%]Threshold
21.287.08
1.561.5687.85
1.32.088.51
12.689.11
0.54.390.32
0.28.391.98

In the Core Server version 6.12.0, we recommend following thresholds based on the use case:

  • 87 Optimized for user convenienece
  • 88.5 Standard setting
  • 91 To ensure high security

Thresholds for Core Server 6.11.0

FAR [%]FRR [%]Threshold
21.385.34
1.681.6885.98
1.41.986.57
12.787.40
0.54.288.76
0.27.790.46

Thresholds for Core Server 6.8.0, 6.9.0 and 6.10.0

FAR [%]FRR [%]Threshold
50.285.55
21.188.36
12.289.76
0.53.990.87
0.335.291.45
0.28.192.23

Thresholds for Core Server 6.7.1 and older

FAR [%]FRR [%]Threshold
50.7-37
23.5377
17.9871
0.512.21303
0.3317.21829
0.225.22645

Example

Let’s set the threshold of passive liveness for Core Server 6.17.0 to 88.08. If we have a representative set of 10000 real faces, statistically 187 of the faces will be in average incorrectly marked as spoofs even though they were real faces (False Reject Rate). If we have set of 10000 spoofs, statistically 10 of the spoofs will be in average wrongly marked as real faces (False Accept Rate).


Setting the correct threshold depends on the security/convenience balance that is required for the specific use case.

Integration hint

During the initial configuration of the system, two thresholds can be set. If the score is below the bottom threshold, result is automatically set to rejected. If the score is above the top threshold it is automatically accepted. If the score is between the two thresholds, images go for review to a back office operator for final decision.


Note

Passive liveness has to be always combined with face matching if possible. Passive liveness ensures the presented face is real, but it must be also checked whether it belongs to the person expected. This applies for onboarding and login use cases.