About the Biometric Authenticator

The Biometric Authenticator leverages the native biometry authentication provided by the device operating system.

All menus and menu prompts that are presented to your users during the usage of the biometric authenticators come directly from the operating systems. Messages and content of these menus and prompts can only be customized to the extent permitted by Android and iOS.

Biometric behavior

If you decide to integrate this authenticator, note that there will be no fallback option to other authentication methods, either in the menu prompt or when biometric authentication fails.

iOS

On iOS, four separate biometric authenticators are provided, TouchID (restricted or normal) and FaceID (restricted or normal).

• FaceID/TouchID authenticators: These authenticators allow changes to the currentry enrolled biometry set—as long as the biometry scan is successful, the process can be continued. Adding or removing fingerprints or face IDs does not affect the registration.

• Restricted FaceID/TouchID authenticators: These authenticators rely on the currently enrolled biometry set on the device. If the user modifies the device's enrolled biometry set either by adding a new fingerprint or face ID or removing an existing one, the key is permanently removed and cannot be recovered.

Android

On Android, one authenticator is provided, Restricted Biometric Authenticator. It is configured to use the Strong Biometry feature, such as fingerprint, to perform the crypto-based authentication. It is limited to the current biometry set at the time of registration. If there are any changes to the currently-enrolled biometry set, the crypto key will be permanently removed and cannot be recovered.

Key management

All keys used for authenticators are stored in the secure hardware element of the device and protected by biometry. The keys cannot be shared. They will never leave the device and will not migrate from one device to another by a backup/restore process.

Per user, only one authenticator and app ID can be registered on the same device. This means that if a user already has a registration in an authenticator for an application on this device, a new registration CANNOT be created in the same authenticator on the same device for that user and application.

Anti-hammering protection

The anti-hammering protection counts the number of unsuccessful authentication attempts and applies a penalty after a defined threshold of attempts. The anti-hammering protection is provided by the operating system on Android and iOS and can therefore not be configured.

Android

Based on the operating system behavior, the biometry prompt will add a delay after a number of failed authentication attempts. After exceeding the failure count threshold, the biometric authentication is disabled until the user unlocks the device with their device credentials, such as a PIN, pattern, or password.

If the anti-hammering is triggered on the level of the operating system, BiometricAuthenticatorError can be thrown.

iOS

Based on the operating system behavior, the biometry prompt will no longer display after a number of failed authentication attempts. The biometry prompt will not return until the device PIN is entered somewhere in the interface, such as the lock screen.

If the anti-hammering is triggered on the level of the operating system, BiometricAuthenticatorError can be thrown.

Metadata for the Biometric Authenticators

The metadata for the Biometric Authenticator is typically stored in the FIDO Metadata Service, which FIDO relying parties can access to obtain information about the authenticators. The metadata is essential for enabling interoperability and security in the FIDO environment. The following table describes the Authenticator Attestation IDs (AAIDs) for the Biometric Authenticator.