Each authenticator is identified by a unique authenticator model identifier. For example, a UAF authenticator is identified by its Authenticator Attestation ID (AAID). For a given authentication method, for example fingerprint, there can be several AAIDs that reflect different implementation characteristics. These characteristics include the crypto algorithm used, or whether the authenticator uses a hardware or software keystore.
Nok Nok has created predefined authenticator groups, described below, that contain authenticators with common characteristics. You can use these authenticator groups to specify valid authenticators allowed by FIDO policies.
Predefined Authenticator Groups | Group Description |
|---|---|
Android/iOS Strong Biometric - Hardware | Biometrics on iOS and Class 3 biometric authenticators on Android, with a hardware keystore. Includes single-device passkeys. May exclude older Android device biometrics. |
Android/iOS Any Biometric - Hardware | Includes all iOS and Android Class 3 biometric authenticators as well as Android Class 2 biometric authenticators, with a hardware keystore. Includes single-device passkeys. |
Android/iOS Lock Screen - Hardware | Lock Screen/Passcode authenticators for Android and iOS, with a hardware keystore. |
Android/iOS PIN - Hardware | PIN authenticators for Android and iOS, with a hardware keystore. |
Android/iOS Presence - Hardware | Presence (Yes/No) authenticators for Android and iOS, with a hardware keystore. |
Android/iOS Silent - Hardware | Silent authenticators for Android and iOS with a hardware keystore. |
Android/iOS Platform | The FIDO2 authenticators supported by Android and iOS (passkey). |
You can also find the list of included authenticators in the S3 Suite. The App SDK for Android and iOS includes components that are suitable for enabling FIDO-based authentication on devices lacking a native FIDO Certified™ authenticator.
Friendly Authenticator Naming
The authenticator name is generated using information in the authenticator metadata. During registration, the Server looks up the metadata, if available, and generates the name.
For example, if the AAGUID is fbfc3007-154e-4ecc-8c0b-6e020557d7bd, and the metadata contains the following:
"description": "iCloud Keychain",
"alternativeDescriptions" : {
"es-US": "El llavero de iCloud",
"de-DE": "iCloud-Schlüsselbund"
},then the name will be "iCloud Keychain". If the client sends the locale such as "es-US", then "El llavero de iCloud" will be the name.
If the metadata doesn't exist, then the name will be the alternate name that is sent by the client such as "Passkey on iCloud Keychain".