1.1 Key Words

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

5.1 Request from Client to Authenticator

Request frames must have the following format

Supported commands are PING and MSG. The constant values for them are described below.

The data format for the MSG command is defined in [U2FRawMsgs]. For the U2F over Bluetooth protocol, U2F raw messages are encoded using extended length APDU encoding.

5.2 Response from Authenticator to Client

Response frames must have the following format, which share a similar format to the request frames:

When the status byte in the response is the same as the command byte in the request, the response is a successful response. The value ERROR indicates an error, and the response data contains an error code as a variable-length, big-endian integer. The constant value for ERROR is described below.

Note that the errors sent in this response are errors at the encapsulation layer, e.g., indicating an incorrectly formatted request, or possibly an error communicating with the Authenticator’s U2F message processing layer. Errors reported by the U2F message processing layer itself are considered a success from the encapsulation layer’s point of view, and are reported as a complete MSG response.

Data format is defined in [U2FRawMsgs]. Note that as per [U2FRawMsgs] (and unlike the NFC transport specification), all communication SHALL be done using extended length APDU format.

5.3 Command, Status, and Error constants

The COMMAND constants and values are:

The KEEPALIVE command contains a single byte with the following possible values:

A resulting Keep alive message, including framing, becomes:

The ERROR constants and values are:

6.1 U2F Service

An Authenticator SHALL implement the U2F Service described below. The UUID for the FIDO U2F GATT service is 0xFFFD, it shall be declared as a Primary Service. The service contains the following characteristics:

u2fControlPoint is a write-only command buffer.

u2fStatus is a notify-only response attribute. The Authenticator will send a series of notifications on this attribute with a maximum length of (ATT_MTU-3) using the response frames defined above. This mechanism is used because this results in a faster transfer speed compared to a notify-read combination.

u2fControlPointLength defines the maximum size in bytes of a single write request to u2fControlPoint. This value SHALL be between 20 and 512.

u2fServiceRevision defines the revision of the U2F Service. The value is a UTF-8 string. For version 1.0 of the specification, the value u2fServiceRevision SHALL be 1.0 or in raw bytes: 0x312e30. This field SHALL be omitted if protocol version 1.0 is not supported.

u2fServiceRevisionBitfield defines the revision of the U2F Service. The value is a bit field. Each bit represents the Authenticator's support of a particular protocol version. A bit value of 1 indicates support, while value 0 indicates lack of support. The length of the bitfield is 1 or more bytes. All bytes that are 0 are omitted if all the following bytes are 0 too. The bit field is big endian encoded with the most significant bit representing version 1.1 support, the next most significant bit, representing the next protocol version, etc. If only version 1.0 is supported, this characteristic SHALL be omitted. If the u2fServiceRevision characteristic is present or more than 1 bit in this u2fServiceRevisionBitfield characteristic is 1, the client SHALL write the value of the requested protocol version to be used for the lifetime of this connection. If u2fServiceRevision characteristic is not present and only one bit in u2fServiceRevisionBitfield is set, the version that bit represents SHALL be the default.

The u2fServiceRevision Characteristic MAY include a Characteristic Presentation Format descriptor with format value 0x19, UTF-8 String.

6.2 Device Information Service

An Authenticator SHALL implement the Device Information Service [BluetoothDIS] with the following characteristics:

• Manufacturer Name String
• Model Number String
• Firmware Revision String

All values for the Device Information Service are left to the vendors. However, vendors should not create uniquely identifiable values so that Authenticators do not become a method of tracking users.

6.3 Generic Access Profile service

Every Authenticator SHALL implement the Generic Access Profile service [BluetoothGAS] with the following characteristics:

• Device Name
• Appearance

13.1 Bluetooth pairing: Client considerations

As noted in the Pairing section, a disadvantage of using standard Bluetooth pairing is that the pairing is "system-wide" on most operating systems. That is, if an Authenticator is paired to a FIDO Client which resides on an operating system where Bluetooth pairing is "system-wide", then any application on that device might be able to interact with an Authenticator. This poses both security and privacy risks to users.

While Client operating system security is partly out of FIDO's scope, further revisions of this specification MAY propose mitigations for this issue.

13.2 Bluetooth pairing: Authenticator considerations

The method to put the Authenticator into Pairing Mode should be such that it is not easy for the user to do accidentally especially if the pairing method is Just Works. For example, the action could be pressing a physically recessed button or pressing multiple buttons. A visible or audible cue that the Authenticator is in Pairing Mode should be considered. As a counter example, a silent, long press of a single non-recessed button is not advised as some users naturally hold buttons down during regular operation.

Note that at times, Authenticators may legitimately receive communication from an unpaired device. For example, a user attempts to use an Authenticator for the first time with a new Client: he turns it on, but forgets to put the Authenticator into pairing mode. In this situation, after connecting to the Authenticator, the Client will notify the user that he needs to pair his Authenticator. The Authenticator should make it easy for the user to do so, e.g., by not requiring the user to wait for a timeout before being able to enable pairing mode.

Some Client platforms (most notably iOS) do not expose the AD Flag LE Limited and General Discoverable Mode bits to applications. For this reason, Authenticators are also strongly recommended to include the Service Data field [BluetoothSD] in the Scan Response. The Service Data field is 3 or more octets long. This allows the Flags field to be extended while using the minimum number of octets within the data packet. All octets that are 0x00 are not transmitted as long as all other octets after that octet are also 0x00 and it is not the first octet after the service UUID. The first 2 bytes contain the FIDO Service UUID, the following bytes are flag bytes.

To help Clients show the correct UX, Authenticators can use the Service Data field to specify whether or not Authenticators will require a Passkey (PIN) during pairing.

13.3 Handling command completion

It is important for low-power devices to be able to conserve power by shutting down or switching to a lower-power state when they have satisfied a Client's requests. However, the U2F protocol makes this hard as it typically includes more than one command/response. This is especially true if a user has more than one key handle associated with an account or identity, multiple key handles may need to be tried before getting a successful outcome. Furthermore, Clients that fail to send follow up commands in a timely fashion may cause the Authenticator to drain its battery by staying powered up anticipating more commands.

A further consideration is to ensure that a user is not confused about which command she is confirming by completing the test of user presence. That is, if a user performs the test of user presence, that action should perform exactly one operation.

We combine these considerations into the following series of recommendations:

• Upon initial connection to an Authenticator, and upon receipt of a response from an Authenticator, if a Client has more commands to issue, the Client MUST transmit the next command or fragment within kMaxCommandTransmitDelayMillis milliseconds.
• Upon final response from an Authenticator, if the Client decides it has no more commands to send it should indicate this by disabling notifications on the u2fStatus characteristic. When the notifications are disabled the Authenticator may enter a low power state or disconnect and shut down.
• Any time the Client wishes to send a U2F APDU, it must have first enabled notifications on the u2fStatus characteristic and wait for the ATT acknowledgment to be sure the Authenticator is ready to process APDU messages.
• Upon successful completion of a command which required a test of user presence, e.g. upon a successful authentication or registration command, the Authenticator can assume the Client is satisfied, and MAY reset its state or power down.
• Upon sending a command response that did not consume a test of user presence, the Authenticator MUST assume that the Client may wish to initiate another command, and leave the connection open until the Client closes it or until a timeout of at least kErrorWaitMillis elapses. Examples of command responses that do not consume user presence include failed authenticate or register commands, as well as get version responses, whether successful or not. After kErrorWaitMillis milliseconds have elapsed without further commands from a Client, an Authenticator MAY reset its state or power down.

13.4 Data throughput

Bluetooth low energy technology does not have particularly high throughput, this can cause noticeable latency to the user if request/responses are large. Some ways that implementers can reduce latency are:

• Support the maximum MTU size allowable by hardware (up to the 512 bytes max from the Bluetooth specifications).
• Make the attestation certificate as small as possible, do not include unnecessary extensions.

13.5 Advertising

Though the standard doesn’t appear to mandate it (in any way that we’ve found thus far), advertising and device discovery seems to work better when the Authenticators advertise on all 3 advertising channels and not just one.

13.6 Authenticator Address Type

In order to enhance the user's privacy and specifically to guard against tracking, it is recommended that Authenticators use Resolvable Private Addresses (RPAs) instead of static addresses.