REQUIRED_IF_SUPPORTED to REQUIRED.
To configure the validation strategy:
To learn more, see our Hardware-protected keys feature documentation.
You can now control whether you receive an event when the device state changes by passing the generateEvent=true query parameter for the Update device operation.
If generateEvent is omitted, it defaults to false, and no event is generated.
To learn more, see the Update device endpoint in our MobileID API reference documentation.
Our ReuseID API is extended with a new resource for MobileID device hash management.
The new endpoints allow you to retrieve a list of devices associated with a given device hash and lock all devices associated with that hash. You can read more about this in our ReuseID API reference documentation using the links below.
To learn more, see the following endpoints in the ReuseID API reference documentation:
You can now control whether you receive an event when the device state changes by passing the generateEvent=true query parameter for the Update device operation.
If generateEvent is omitted, it defaults to false, and no event is generated.
To learn more, see the Update device operation in our ReuseID API reference documentation.
We have moved the following two operations from the Statistics resource in the Admin API to the MobileID device hash management resource in the ReuseID API:
To align with our other services, we have changed the context path for the Get device hash statistics operation from devicehashes to device-hashes.
This context path change is not backward compatible.
device-hashes context path.algorithm property to the Add E2E key endpoint in the Admin API.
With this property, you can explicitly select the algorithm used for key exchange between the SDK and the server.
The default algorithm for newly generated E2EE keys has changed to X25519.
For apps using an SDK version earlier than 3.22, you must generate E2EE keys with the SECT233K1 algorithm.
Before you upgrade your app to SDK 3.22 or later, you must rotate your E2EE key to one that uses the X25519 algorithm.
To learn how to do this, see the Key rotation section in our End-to-end encryption feature documentation.
To configure it yourself:
To learn more, see our Hardware-protected keys feature documentation.
Now, you can choose between either:
| Validation strategy | Description |
|---|---|
REQUIRED_IF_SUPPORTED | Enforces hardware key validation if the device supports hardware keys. Note: This is the default strategy. |
REQUIRED | Enforces hardware key validation for all devices. |
This is configured with the hwKeyValidationStrategy property in your application configuration, using the Admin API.
To learn more, see the:
The lock scope determines the lock behaviour following failed authentication attempts. This can be either:
To configure it yourself:
To learn more, see the lockScope property in the Application behaviour section of our Application configuration feature documentation.
These new endpoints allow you to easily manage risk data for your integrations.
To learn more:
The device hash is designed to be persistent and unique for a mobile device within your app.
If the same device hash is present across multiple users, it could suggest that one malicious individual is using a single device to gain access to numerous accounts for unauthorised activities and account takeovers.
On this new page, you can see:
You can also find detailed information about the users and devices associated with the flagged device hashes, such as when the device was last used and its status.
To try it out yourself, see the Device hash page under the Risk indicators section in the Signicat Dashboard!
To learn more, see the Device hash page in the Risk indicators feature documentation.
On the MobileID Overview page in the Signicat Dashboard, you can see transaction statistics for MobileID devices.
Previously, only statistics for MobileID customers using the MobileID REST API were shown. In this release, we have extended the scope to include device statistics for:
These statistics provide you with an activity overview of the following for the last 30 days:
The new endpoints allow you to retrieve statistics about devices, users and device hashes, in addition to reviewing or locking flagged device hashes.
You can read more about this in the Admin API reference documentation using the links below.
To learn more, see the following endpoints in the Admin API reference documentation:
Device statistics are for active MobileID devices. A MobileID device is active if it has performed at least one operation in the last six months.
On this new page, you can find the following information:
To try it out yourself, see the Statistics page in the Signicat Dashboard!
]]>This feature was deprecated on 30.10.2024.
To replace this feature, you can use our ReuseID solution instead.
It allows you to perform ID document and biometric verification for either onboarding end-users to MobileID or existing MobileID users.
To learn more, see ReuseID in the Signicat developer documentation.
| Category | Description |
|---|---|
| Sensor insights | These attributes give you access to motion and environmental sensor data, to support advanced behavioural or situational analysis: magnetometer, gravity, barometer. |
| Network context | These attributes enable you to evaluate the trust level of the network connection and identify potential spoofing or untrusted Wi-Fi environments: ssid, bssid, isVpnEnabled, isProxyEnabled. |
| Device integrity | These attributes enable you to detect signs of tampering or unsafe configurations that may indicate a compromised device: isDeveloperMode, isOverlayDetected. |
| Locale & environment | These attributes enable you to gain better understanding of the end-user's regional context and time-based patterns for anomaly detection: timeZone, locale. |
To collect these new risk attributes, you need to both:
To learn more, see the Risk attributes Common concepts table in the MobileID API reference documentation.
To have a consistent naming scheme, we have changed the name of recovery method CLOUD_BACKUP to CLOUD_BACKUP_RECOVERY_CODE.
To learn more, see the following endpoints in the MobileID API reference documentation:
We have improved the database lock handling so that multiple concurrent requests for the same device get a proper error message, instead of an HTTP 500 error.
To learn more, see the following endpoints in the MobileID API reference documentation:
We have rewritten most event type names to make them more readable. They now follow a general pattern of ORIGIN_ACTION_EVENT.
To see all changes, together with the previous naming scheme, see:
We have removed the purpose field, as the purpose is already a part of the event type name.
This endpoint will be completely removed in the near future.
If you need to get the full final result of an executed passport scan, then you can contact us by creating a support ticket in the Signicat Dashboard.
]]>This feature was deprecated on 30.10.2024.
To replace this feature, you can use our ReuseID solution instead.
To learn more, see ReuseID in the Signicat developer documentation.
This authentication method is:
To retrieve information about how the account recovery was performed, the Get details of account recovery response has been extended with two new properties: recoveryMethod and recoveryStatus.
To learn more:
lockReason attribute from the device object in the MobileID API.
To get the lock reason, you must now use the Get device endpoint for the MobileID Device management resource.
The lock reason is then returned in the deviceDetails object, so you must use query parameter detailed=true.
Although it is still possible to pass the lockReason attribute in the request body when using the Update device endpoint, it is no longer applied.
This means that there are no longer restrictions on what letters, digits or special characters the device name can contain or must start with.
The device name must still not exceed the maximum character length.