Application configuration

Introduction

An application configuration is a specific set of application attributes for a mobile application.

Each application configured on the Encap server needs its own set of configuration attributes, and these determine how the application should work.

How does it work?

Application configurations are loaded from the Encap server database.

If no application configuration is found in the Encap server database, then the server is started with a default application configuration which has encap as the app ID.

Any value not specified in the application configuration will be set to the default value shown in the tables below.

You can use the REST API to maintain application configurations at runtime. This means that you can add, modify and remove properties without the need to restart the server.

Properties

In the tables below, you can find an overview of all application configuration properties and their default values.

Account recovery

You can use the properties below to configure account recovery for your application.

Want to learn more?

To learn more about this feature, see our Account recovery feature documentation.

App attestation

The configuration is split into a set of properties for Play Integrity (Android) and App Attest (iOS).

You can use the properties in the tables below to configure app attestation for your application, according to the mobile platform.

Want to learn more?

To learn more about this feature, see our App attestation feature documentation.

Play Integrity (Android)

Properties to configure app attestation for your Android application.

Mandatory configurations

If ATTESTATION_ANDROID_PLAY_INTEGRITY_MODE is set to REQUIRED or OPTIONAL, then all Play Integrity configurations defined in the table below are required.

App Attest (iOS)

Properties to configure app attestation for your iOS application.

Mandatory configurations

If ATTESTATION_IOS_APP_ATTEST_MODE is set to REQUIRED or OPTIONAL, then all App Attest configurations defined in the table below are required.

How do attestation modes work?

The app attestation feature can be used in multiple modes. The modes are the same for Android and iOS, and are set using the following properties:

• ATTESTATION_ANDROID_PLAY_INTEGRITY_MODE (Android)
• ATTESTATION_IOS_APP_ATTEST_MODE (iOS)

Application behaviour

You can use the properties below to configure the behaviour of your application.

How does guess probability work?

With the ACTIVATION_CODE_ALLOWED_GUESS_PROBABILITY property, you can set the lower limit for how guessable the activation code is.

The Encap server calculates the guess probability based on the cardinality of:

• The activation code type.
• The activation code length.
• The number of active activations.

This means that in order to increase the number of concurrently active activations supported, you must either:

• Increase the ACTIVATION_CODE_LENGTH.
• Choose an ACTIVATION_CODE_TYPE with greater cardinality.

Example: Demonstration of allowed guess probability

Click to expand

With ACTIVATION_CODE_LENGTH = 4 and ACTIVATION_CODE_TYPE = NUMERIC, there are 10,000 possible activation codes. This means that with one activation in progress, the chance of guessing the activation code is 1 in 10,000.

With 10 concurrent activations in progress, the chance of guessing a valid activation code is reduced to 1 in 1,000:

10000 ÷ 10 = 1000

If an 11th activation session starts before any of the others finish, then it will fail the ACTIVATION_CODE_ALLOWED_GUESS_PROBABILITY check. This is because the chance is below 1 in 1,000:

10000 ÷ 11 = 909.09

How does minimum required Encap version work?

With the MINIMUM_REQUIRED_ENCAP_API_VERSION_ANDROID and MINIMUM_REQUIRED_ENCAP_API_VERSION_IOS properties, you can set the minimum client SDK version allowed.

The parameter for specifying the minimum required Encap version can only be used to narrow down the allowed SDK versions, not extend the range.

Example: Demonstration of minimum required Encap version

Click to expand

If the minimum supported client version on the server is version "3.5.0", but you want to only allow version "3.6.0", then you can achieve this by setting "3.6.0" as the value for this property.

However, if set "3.3.0" as the value for this property, then it would have no effect. This is because it is below the minimum supported client version on the server.

Client debug data

You can use the properties below to configure client debug data for your application.

Want to learn more?

To learn more about this feature, see our Client debug data feature documentation.

Client request validation

Event callback

You can use the properties below to configure event callback for your application.

How does event callback work?

With the EVENT_CALLBACK_EVENTS property, you can set a comma-separated list of events that you would like to trigger a REST callback to the configured service provider URL.

For further control of when callback should be issued, you can filter events per API. If an API is not specified, then the callback for the event will be sent regardless of API.

Example: Format specification

<EVENT_TYPE_1>:[<API_1>|<API_2>|<…>],<EVENT_TYPE_1>:[<API_1>|<API_2>|<…>]

Example: Demonstration of event callback

Click to expand

Example 1: Event callback

If you set:

DEVICE_LOCKED, DEVICE_DEACTIVATED:[REST]

Then callback for DEVICE_LOCKED is triggered regardless of which API initiated it, and callback for DEVICE_DEACTIVATED is triggered when you deactivate a device from the REST API.

Example 2: Event callback

If you set:

DEVICE_LOCKED, DEVICE_DEACTIVATED:[DEVICE]

Then callback for DEVICE_LOCKED is triggered regardless of which API initiated it, and callback for DEVICE_DEACTIVATED is triggered when the end-user initiates a deactivation request from the mobile app.

Face authentication

You can use the property below to configure face authentication for your application.

Want to learn more?

To learn more about this feature, see our Face authentication feature documentation.

Geofencing

You can use the properties below to configure geofencing for your application.

The configuration is split into a set of properties for activation (registration/enrolment) and authentication, so that you can enforce different rules for the different operations.

Want to learn more?

To learn more about this feature, see our Geofencing feature documentation.

How do geofencing modes work?

The app attestation feature can be used in multiple modes. The modes are the same for activation and authentication operations, and are set using the following properties:

• GEOFENCING_ACTIVATION_MODE (activation/registration/enrolment operations)
• GEOFENCING_AUTHENTICATION_MODE (authentication operations)

Hardware-protected keys

You can use the properties below to configure hardware-protected keys for your application.

Want to learn more?

To learn more, see our Hardware-protected keys feature documentation.

Push notifications

You can use the properties below to configure push notifications for your application.

Want to learn more?

To learn more, see our Push notifications feature documentation.

Risk data

You can use the property below to configure risk data for your application.