Abstract
This document defines all the strings and constants reserved by FIDO protocols.
The values defined in this document are referenced by various FIDO specifications.
Status of This Document
This section describes the status of this document at the time of its publication.
Other documents may supersede this document. A list of current FIDO Alliance publications and the
latest revision of this technical report can be found in the FIDO Alliance specifications index at
https://fidoalliance.org/specifications/.
This document was published by the FIDO Alliance as a Proposed Standard.
If you wish to make comments regarding this document, please
Contact Us.
All comments are welcome.
Implementation of certain elements of this Specification may require licenses under third party intellectual
property rights, including without limitation, patent rights. The FIDO Alliance, Inc. and its Members
and any other contributors to the Specification are not, and shall not be held, responsible in any manner
for identifying or failing to identify any or all such third party intellectual property rights.
THIS FIDO ALLIANCE SPECIFICATION IS PROVIDED “AS IS” AND WITHOUT ANY
WARRANTY OF ANY KIND, INCLUDING, WITHOUT LIMITATION, ANY EXPRESS OR IMPLIED
WARRANTY OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
This document has been reviewed by FIDO Aliance Members
and is endorsed as a Proposed Standard.
It is a stable document and may be used as reference material or cited from another
document. FIDO Alliance's role in making the Recommendation is to draw attention to the
specification and to promote its widespread deployment.
1. Notation
Type names, attribute names and element names are written as code.
String literals are enclosed in “”, e.g. “UAF-TLV”.
In formulas we use “|” to denote byte wise concatenation operations.
FIDO specific terminology used in this document is defined in [FIDOGlossary].
Some entries are marked as "(optional)" in this spec. The meaning of this is defined
in other FIDO specifications referring to this document.
3. Authenticator Characteristics
This section is normative.
3.1 User Verification Methods
The USER_VERIFY constants are flags in a bitfield represented
as a 32 bit long integer. They describe
the methods and capabilities of a FIDO authenticator for locally verifying
a user. The operational details of
these methods are opaque to the server. These constants are used in the
authoritative metadata for FIDO authenticators,
reported and queried through the UAF Discovery APIs, and used to form authenticator
policies in UAF protocol messages. Each constant has a case-sensitive string representation (in quotes),
which is used in the authoritative metadata for FIDO authenticators.
All user verification methods labeled "_INTERNAL" must be performed entirely inside the authenticator boundary
[FIDOAuthenticatorSecurityRequirements] (gathering of data, processing of data and matching of the data).
This version of the document makes the previous assumption of implementing the user verification methods inside
the authenticator boundary explicit by adding the _INTERNAL suffix to the name. That is,
the _INTERNAL suffix doesn't change the previous meaning, it just makes this meaning more explicit.
All user verification methods labeled "_EXTERNAL" can use data gathered and pre-processed outside the authenticator boundary,
but must perform the matching entirely inside the authenticator boundary.
USER_VERIFY_PRESENCE_INTERNAL 0x00000001 "presence_internal"- This flag MUST be set if the authenticator is able to confirm user presence
in any fashion. If this flag and no
other is set for user verification, the guarantee is only that the authenticator
cannot be operated without some human
intervention, not necessarily that the sensing of "presence" provides
any level of user verification
(e.g. a device that requires a button press to activate).
USER_VERIFY_FINGERPRINT_INTERNAL 0x00000002 "fingerprint_internal"- This flag MUST be set if the authenticator uses any type of measurement of
a fingerprint for user verification.
USER_VERIFY_PASSCODE_INTERNAL 0x00000004 "passcode_internal"- This flag MUST be set if the authenticator uses a local-only passcode
(i.e. a passcode not known by the server) for user verification.
USER_VERIFY_VOICEPRINT_INTERNAL 0x00000008 "voiceprint_internal"- This flag MUST be set if the authenticator uses a voiceprint (also known as speaker recognition)
for user verification.
USER_VERIFY_FACEPRINT_INTERNAL 0x00000010 "faceprint_internal"- This flag MUST be set if the authenticator uses any manner of face recognition
to verify the user.
USER_VERIFY_LOCATION_INTERNAL 0x00000020 "location_internal"- This flag MUST be set if the authenticator uses any form of location sensor
or measurement for user verification.
USER_VERIFY_EYEPRINT_INTERNAL 0x00000040 "eyeprint_internal"- This flag MUST be set if the authenticator uses any form of eye biometrics
for user verification.
USER_VERIFY_PATTERN_INTERNAL 0x00000080 "pattern_internal"- This flag MUST be set if the authenticator uses a drawn pattern for user verification.
USER_VERIFY_HANDPRINT_INTERNAL 0x00000100 "handprint_internal"- This flag MUST be set if the authenticator uses any measurement of a full
hand (including palm-print, hand geometry or vein geometry) for user verification.
USER_VERIFY_PASSCODE_EXTERNAL 0x00000800 "passcode_external"- This flag MUST be set if the authenticator uses a local-only passcode
(i.e. a passcode not known by the server) for user verification
that might be gathered outside the authenticator boundary.
USER_VERIFY_PATTERN_EXTERNAL 0x00001000 "pattern_external"- This flag MUST be set if the authenticator uses a drawn pattern for user verification
that might be gathered outside the authenticator boundary.
USER_VERIFY_NONE 0x00000200 "none"- This flag MUST be set if the authenticator will respond without any
user interaction (e.g. Silent Authenticator).
USER_VERIFY_ALL 0x00000400 "all"- If an authenticator sets multiple flags for the "_INTERNAL" and/or "_EXTERNAL"
user verification types, it MAY
also set this flag to indicate that all verification methods with respective flags set will be enforced
(e.g. faceprint AND voiceprint). If flags for multiple
user verification methods are set and this flag is not set, verification with
only one is necessary (e.g. fingerprint OR passcode).
3.2 Key Protection Types
The KEY_PROTECTION constants are flags in a bit field
represented as a 16 bit long integer. They describe the method an
authenticator uses to protect the private key material for FIDO registrations.
Refer to [UAFAuthnrCommands] for more details on the relevance of keys and
key protection. These constants are reported and queried through the UAF Discovery APIs
and used to form authenticator policies in UAF protocol messages. Each constant has a
case-sensitive string representation (in quotes), which is used in the authoritative
metadata for FIDO authenticators.
When used in metadata describing an authenticator, several of these flags are exclusive of
others (i.e. can not be combined) - the certified metadata may have
at most one of the mutually exclusive string constant values. When used in authenticator
policy, any bit may be set to 1, e.g. to indicate that a server is
willing to accept authenticators using either KEY_PROTECTION_SOFTWARE or
KEY_PROTECTION_HARDWARE.
Note
These flags must be set according to the effective security of the
keys, in order to follow the assumptions made in [FIDOSecRef]. For example, if a key
is stored in a secure element but software running on the FIDO User Device
could call a function in the secure element to export the key either in the clear or using
an arbitrary wrapping key, then the effective security is KEY_PROTECTION_SOFTWARE and
not KEY_PROTECTION_SECURE_ELEMENT.
KEY_PROTECTION_SOFTWARE 0x0001 "software"- This flag MUST be set if the authenticator uses software-based key management.
Exclusive in authenticator metadata with
KEY_PROTECTION_HARDWARE, KEY_PROTECTION_TEE,
KEY_PROTECTION_SECURE_ELEMENT
KEY_PROTECTION_HARDWARE 0x0002 "hardware"- This flag SHOULD be set if the authenticator uses hardware-based key management.
Exclusive in authenticator metadata with
KEY_PROTECTION_SOFTWARE
KEY_PROTECTION_TEE 0x0004 "tee"- This flag SHOULD be set if the authenticator uses the Trusted Execution
Environment [TEE] for key management. In authenticator metadata,
this flag should be set in conjunction with
KEY_PROTECTION_HARDWARE.
Mutually exclusive in authenticator metadata with
KEY_PROTECTION_SOFTWARE, KEY_PROTECTION_SECURE_ELEMENT
KEY_PROTECTION_SECURE_ELEMENT 0x0008 "secure_element"- This flag SHOULD be set if the authenticator uses a
Secure Element [SecureElement] for key management. In authenticator metadata,
this flag should be set in conjunction with
KEY_PROTECTION_HARDWARE.
Mutually exclusive in authenticator metadata with
KEY_PROTECTION_TEE, KEY_PROTECTION_SOFTWARE
KEY_PROTECTION_REMOTE_HANDLE 0x0010 "remote_handle"- This flag MUST be set if the authenticator does not store (wrapped) UAuth keys
at the client, but relies on a server-provided key handle.
This flag MUST be set in conjunction with one of the other
KEY_PROTECTION
flags to indicate how the local key handle wrapping key and operations are protected.
Servers MAY unset this flag in authenticator policy if they are not prepared to store and return
key handles, for example, if they have a requirement to respond
indistinguishably to authentication attempts against userIDs that do and
do not exist. Refer to [UAFProtocol] for more details.
3.3 Matcher Protection Types
The MATCHER_PROTECTION constants are flags in a bit field
represented as a 16 bit long integer.
They describe the method an authenticator uses to protect the matcher
that performs user verification.
These constants are reported and queried through the UAF Discovery APIs and used
to form authenticator policies in UAF protocol messages. Refer to [UAFAuthnrCommands]
for more details on the matcher component. Each constant has a case-sensitive
string representation (in quotes), which is used in the authoritative metadata
for FIDO authenticators.
Note
These flags must be set according to the effective security of the
matcher, in order to follow the assumptions made in [FIDOSecRef]. For example, if a passcode based
matcher is implemented in a secure element, but the passcode is expected to be
provided as unauthenticated parameter, then the effective security
is MATCHER_PROTECTION_SOFTWARE and
not MATCHER_PROTECTION_ON_CHIP.
MATCHER_PROTECTION_SOFTWARE 0x0001 "software"- This flag MUST be set if the authenticator's matcher is running in software.
Exclusive in authenticator metadata with
MATCHER_PROTECTION_TEE,
MATCHER_PROTECTION_ON_CHIP
MATCHER_PROTECTION_TEE 0x0002 "tee"- This flag SHOULD be set if the authenticator's matcher is running inside
the Trusted Execution Environment [TEE]. Mutually exclusive in authenticator metadata with
MATCHER_PROTECTION_SOFTWARE,
MATCHER_PROTECTION_ON_CHIP
MATCHER_PROTECTION_ON_CHIP 0x0004 "on_chip"- This flag SHOULD be set if the authenticator's matcher is running on the chip.
Mutually exclusive in authenticator metadata with
MATCHER_PROTECTION_TEE,
MATCHER_PROTECTION_SOFTWARE
3.4 Authenticator Attachment Hints
The ATTACHMENT_HINT constants are flags in a bit field
represented as a 32 bit long. They describe the method FIDO
authenticators use to communicate with the FIDO User Device. These constants are reported and
queried through the UAF Discovery APIs [UAFAppAPIAndTransport], and used to form Authenticator
policies in UAF protocol messages. Because the connection
state and topology of an authenticator may be transient, these values are
only hints that can be used by server-supplied policy
to guide the user experience, e.g. to prefer a device that is connected and
ready for authenticating or confirming a low-value transaction,
rather than one that is more secure but requires more user effort. Each constant
has a case-sensitive string representation (in quotes), which is used in the authoritative metadata
for FIDO authenticators.
Note
These flags are not a mandatory part of authenticator metadata and,
when present, only indicate possible states that may be reported during
authenticator discovery.
ATTACHMENT_HINT_INTERNAL 0x0001 "internal"- This flag MAY be set to indicate that the authenticator is permanently attached
to the FIDO User Device.
A device such as a smartphone may have authenticator functionality
that is able to be used both locally and remotely.
In such a case, the FIDO client MUST filter and exclusively
report only the relevant bit during Discovery and when performing policy matching.
This flag cannot be combined with any other ATTACHMENT_HINT flags.
ATTACHMENT_HINT_EXTERNAL 0x0002 "external"- This flag MAY be set to indicate, for a hardware-based authenticator, that
it is removable or remote from the FIDO User Device.
A device such as a smartphone may have
authenticator functionality that is able to be used
both locally and remotely. In such a case, the FIDO UAF Client MUST filter and
exclusively report only the relevant bit during
discovery and when performing policy matching.
This flag MUST be combined with one or more other ATTACHMENT_HINT flag(s).
ATTACHMENT_HINT_WIRED 0x0004 "wired"- This flag MAY be set to indicate that an external authenticator currently has an exclusive
wired connection, e.g. through USB, Firewire
or similar, to the FIDO User Device.
ATTACHMENT_HINT_WIRELESS 0x0008 "wireless"- This flag MAY be set to indicate that an external authenticator communicates with the FIDO User Device
through a personal area or otherwise non-routed wireless protocol, such as Bluetooth or NFC.
ATTACHMENT_HINT_NFC 0x0010 "nfc"- This flag MAY be set to indicate that an external authenticator is able to communicate by NFC
to the FIDO User Device. As part of
authenticator metadata, or when reporting characteristics through discovery, if this flag is set, the
ATTACHMENT_HINT_WIRELESS flag SHOULD also be set as well.
ATTACHMENT_HINT_BLUETOOTH 0x0020 "bluetooth"- This flag MAY be set to indicate that an external authenticator is able to communicate using
Bluetooth with the FIDO User Device.
As part of authenticator metadata, or when reporting characteristics through
discovery, if this flag is set, the
ATTACHMENT_HINT_WIRELESS flag SHOULD also be set.
ATTACHMENT_HINT_NETWORK 0x0040 "network"- This flag MAY be set to indicate that the authenticator is connected to the FIDO User Device
over a non-exclusive network (e.g. over a TCP/IP LAN or WAN, as opposed
to a PAN or point-to-point connection).
ATTACHMENT_HINT_READY 0x0080 "ready"- This flag MAY be set to indicate that an external authenticator is in a "ready" state. This flag
is set by the ASM at its discretion.
Note
Generally this should indicate that the device is immediately available to
perform user verification without additional
actions such as connecting the device or creating a new biometric
profile enrollment, but the exact meaning may vary for
different types of devices. For example, a USB authenticator may only
report itself as ready when it is plugged in,
or a Bluetooth authenticator when it is paired and connected, but an
NFC-based authenticator may always report itself as ready.
ATTACHMENT_HINT_WIFI_DIRECT 0x0100 "wifi_direct"- This flag MAY be set to indicate that an external authenticator is able to communicate using
WiFi Direct with the FIDO User Device.
As part of authenticator metadata and when reporting characteristics
through discovery, if this flag is set, the
ATTACHMENT_HINT_WIRELESS flag SHOULD also be set.
3.5 Transaction Confirmation Display Types
The TRANSACTION_CONFIRMATION_DISPLAY constants are flags
in a bit field represented as a 16 bit long
integer. They describe the availability and implementation of a
transaction confirmation display capability required
for the transaction confirmation operation. These constants are
reported and queried through the UAF Discovery APIs and used to
form authenticator policies in UAF protocol messages. Each constant
has a case-sensitive string representation (in quotes), which is used
in the authoritative metadata for FIDO authenticators.
Refer to [UAFAuthnrCommands] for more details on the security aspects
of TransactionConfirmation Display.
TRANSACTION_CONFIRMATION_DISPLAY_ANY 0x0001 "any"- This flag MUST be set to indicate that a transaction confirmation
display, of any type, is available on this authenticator.
Other
TRANSACTION_CONFIRMATION_DISPLAY flags MAY also be set if this flag is set.
If the authenticator does not support a transaction confirmation display, then the value of
TRANSACTION_CONFIRMATION_DISPLAY MUST be set to 0.
TRANSACTION_CONFIRMATION_DISPLAY_PRIVILEGED_SOFTWARE
0x0002 "privileged_software"- This flag MUST be set to indicate, that a software-based transaction confirmation
display operating in a privileged context is available on this authenticator.
A FIDO client that is capable of providing this
capability MAY set this bit (in conjunction with TRANSACTION_CONFIRMATION_DISPLAY_ANY)
for all authenticators of type
ATTACHMENT_HINT_INTERNAL, even if the authoritative metadata for the
authenticator does not indicate this capability.
Note
Software based transaction confirmation displays might be implemented within
the boundaries of the ASM rather than by the authenticator itself [UAFASM].
TRANSACTION_CONFIRMATION_DISPLAY_TEE
and TRANSACTION_CONFIRMATION_DISPLAY_HARDWARE.
TRANSACTION_CONFIRMATION_DISPLAY_TEE 0x0004 "tee"- This flag SHOULD be set to indicate that the authenticator implements a transaction confirmation
display in a Trusted Execution Environment ([TEE], [TEESecureDisplay]).
This flag is mutually exclusive with
TRANSACTION_CONFIRMATION_DISPLAY_PRIVILEGED_SOFTWARE and
TRANSACTION_CONFIRMATION_DISPLAY_HARDWARE.
TRANSACTION_CONFIRMATION_DISPLAY_HARDWARE 0x0008 "hardware"- This flag SHOULD be set to indicate that a transaction confirmation display based on
hardware assisted capabilities is available on this authenticator.
This flag is mutually exclusive with
TRANSACTION_CONFIRMATION_DISPLAY_PRIVILEGED_SOFTWARE
and TRANSACTION_CONFIRMATION_DISPLAY_TEE.
TRANSACTION_CONFIRMATION_DISPLAY_REMOTE 0x0010 "remote"- This flag SHOULD be set to indicate that the transaction confirmation display
is provided on a distinct device from the FIDO User Device.
This flag can be combined with any other flag.
3.7 Authenticator Attestation Types
The ATTESTATION constants are 16 bit long integers indicating the specific attestation that authenticator supports.
Each constant has a case-sensitive string representation (in quotes), which is used in the authoritative metadata for FIDO authenticators.
ATTESTATION_BASIC_FULL 0x3E07 "basic_full"
Indicates full basic attestation, based on an attestation private key shared among a class of authenticators (e.g. same model). Authenticators must provide its attestation signature during the registration process for the same reason. The attestation trust anchor is shared with FIDO Servers out of band (as part of the Metadata). This sharing process should be done according to [FIDOMetadataService].
ATTESTATION_BASIC_SURROGATE 0x3E08 "basic_surrogate"
Just syntactically a Basic Attestation. The attestation object self-signed, i.e. it is signed using the UAuth.priv key, i.e. the key corresponding to the UAuth.pub key included in the attestation object. As a consequence it does not provide a cryptographic proof of the security characteristics. But it is the best thing we can do if the authenticator is not able to have an attestation private key.
ATTESTATION_ECDAA 0x3E09 "ecdaa"
Indicates use of elliptic curve based direct anonymous attestation as defined in [FIDOEcdaaAlgorithm].
Support for this attestation type is optional at this time. It might be required by FIDO Certification.
ATTESTATION_ATTCA 0x3E0A "attca"
Indicates PrivacyCA attestation as defined in [TCG-CMCProfile-AIKCertEnroll]. Support for this attestation type is optional at this time. It might be required by FIDO Certification.
