Copyright © 2013-2018 FIDO Alliance All Rights Reserved.
This document defines all the strings and constants reserved by FIDO protocols. The values defined in this document are referenced by various FIDO specifications.
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://www.fidoalliance.org/specifications/.
This document was published by the FIDO Alliance as a Review Draft. This document is intended to become a FIDO Alliance Proposed Standard. If you wish to make comments regarding this document, please Contact Us. All comments are welcome.
This is a Review Draft Specification and is not intended to be a basis for any implementations as the Specification may change. Permission is hereby granted to use the Specification solely for the purpose of reviewing the Specification. No rights are granted to prepare derivative works of this Specification. Entities seeking permission to reproduce portions of this Specification for other uses must contact the FIDO Alliance to determine whether an appropriate license for such use is available.
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.
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.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].
This section is non-normative.
This document defines the registry of FIDO-specific constants common to multiple FIDO protocol families. It is expected that, over time, new constants will be added to this registry. For example new authentication algorithms and new types of authenticator characteristics will require new constants to be defined for use within the specifications.
This section is normative.
The USER_VERIFY constants are flags in a bitfield represented
as a 32 bit long integer. They describe
the methods and capabilities of an UAF 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 an authenticator,
reported and queried through the UAF Discovery APIs, and used to form authenticator
policies in UAF protocol messages.
All user verification methods must be performed locally by the authenticator in order to meet FIDO privacy principles.
USER_VERIFY_PRESENCE 0x00000001USER_VERIFY_FINGERPRINT 0x00000002USER_VERIFY_PASSCODE 0x00000004USER_VERIFY_VOICEPRINT 0x00000008USER_VERIFY_FACEPRINT 0x00000010USER_VERIFY_LOCATION 0x00000020USER_VERIFY_EYEPRINT 0x00000040USER_VERIFY_PATTERN 0x00000080USER_VERIFY_HANDPRINT 0x00000100USER_VERIFY_NONE 0x00000200USER_VERIFY_ALL 0x00000400The 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 used in the authoritative metadata for an
authenticator, reported and queried through the UAF Discovery APIs, and used to
form authenticator policies in UAF protocol messages.
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 bits set to 1. 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.
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 0x0001KEY_PROTECTION_HARDWARE, KEY_PROTECTION_TEE,
KEY_PROTECTION_SECURE_ELEMENT
KEY_PROTECTION_HARDWARE 0x0002KEY_PROTECTION_SOFTWARE
KEY_PROTECTION_TEE 0x0004KEY_PROTECTION_HARDWARE.
Mutually exclusive in authenticator metadata with
KEY_PROTECTION_SOFTWARE, KEY_PROTECTION_SECURE_ELEMENT
KEY_PROTECTION_SECURE_ELEMENT 0x0008KEY_PROTECTION_HARDWARE.
Mutually exclusive in authenticator metadata with
KEY_PROTECTION_TEE, KEY_PROTECTION_SOFTWARE
KEY_PROTECTION_REMOTE_HANDLE 0x0010KEY_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.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 used in the authoritative metadata for an authenticator,
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.
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 0x0001MATCHER_PROTECTION_TEE,
MATCHER_PROTECTION_ON_CHIP
MATCHER_PROTECTION_TEE 0x0002MATCHER_PROTECTION_SOFTWARE,
MATCHER_PROTECTION_ON_CHIP
MATCHER_PROTECTION_ON_CHIP 0x0004MATCHER_PROTECTION_TEE,
MATCHER_PROTECTION_SOFTWARE
The ATTACHMENT_HINT constants are flags in a bit field
represented as a 32 bit long. They describe the method an
authenticator uses 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.
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 0x0001A 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 0x0002A 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 0x0004ATTACHMENT_HINT_WIRELESS 0x0008ATTACHMENT_HINT_NFC 0x0010ATTACHMENT_HINT_WIRELESS flag SHOULD also be set as well.ATTACHMENT_HINT_BLUETOOTH 0x0020ATTACHMENT_HINT_WIRELESS flag SHOULD also be set.ATTACHMENT_HINT_NETWORK 0x0040ATTACHMENT_HINT_READY 0x0080Generally 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 0x0100ATTACHMENT_HINT_WIRELESS flag SHOULD also be set.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
used in the authoritative metadata for an authenticator,
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 security aspects
of TransactionConfirmation Display.
TRANSACTION_CONFIRMATION_DISPLAY_ANY 0x0001TRANSACTION_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
0x0002A 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.
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 0x0004TRANSACTION_CONFIRMATION_DISPLAY_PRIVILEGED_SOFTWARE and
TRANSACTION_CONFIRMATION_DISPLAY_HARDWARE.
TRANSACTION_CONFIRMATION_DISPLAY_HARDWARE 0x0008TRANSACTION_CONFIRMATION_DISPLAY_PRIVILEGED_SOFTWARE
and TRANSACTION_CONFIRMATION_DISPLAY_TEE.
TRANSACTION_CONFIRMATION_DISPLAY_REMOTE 0x0010The ATTESTATION constants are 16 bit long integers indicating the specific attestation that authenticator supports.
ATTESTATION_BASIC_FULL 0x3E07ATTESTATION_BASIC_SURROGATE 0x3E08ATTESTATION_ECDAA 0x3E09ATTESTATION_ATTCA 0x3E0A