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://www.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 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.

Table of Contents

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.

DOM APIs are described using the ECMAScript [ECMA-262] bindings for WebIDL [WebIDL].

U2F specific terminology used in this document is defined in [FIDOGlossary].

Symbolic constants such as U2F_REGISTER which are referred to when defining messages in this documents have their values defined in (See [U2FHeader] in bibliography].

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].

2. Introduction

Note: Reading the 'FIDO U2F Overview' (see [U2FOverview] in bibliography) is recommended as a background for this document.

U2F Tokens provide cryptographic assertions that can be verified by relying parties. Typically, the relying party is a web server, and the cryptographic assertions are used as second-factors (in addition to passwords) during user authentication.

U2F Tokens are typically small special-purpose devices that aren't directly connected to the Internet (and hence, able to talk directly to the relying party). Therefore, they rely on a FIDO Client to relay messages between the token and the relying party. Typically, the FIDO Client is a web browser.

The U2F protocol supports two operations, registration and authentication. The registration operation introduces the relying party to a freshly-minted keypair that is under control of the U2F token. The authentication operation proves possession of a previously-registered keypair to the relying party. Both the registration and authentication operation consist of three phases:

  1. Setup: In this phase, the FIDO Client contacts the relying party and obtains a challenge. Using the challenge (and possibly other data obtained from the relying party and/or prepared by the FIDO Client itself), the FIDO Client prepares a request message for the U2F Token.

  2. Processing: In this phase, the FIDO Client sends the request message to the token, and the token performs some cryptographic operations on the message, creating a response message. This response message is sent to the FIDO Client.

  3. Verification: In this phase, the FIDO Client transmits the token's response message, along with other data necessary for the relying party to verify the token response, to the relying party. The relying party then processes the token response and verifies its correctness. A correct registration response will cause the relying party to register a new public key for a user, while a correct authentication response will cause the relying party to accept that the client is in possession of the corresponding private key.

Fig. 1 Three phases of Registration and Authentication

Above is a picture illustrating the three phases.

At the heart of the U2F protocol are the request messages sent to the U2F token, and the response messages received from the U2F token.1

Note that the request message is usually obtained by the FIDO client from the relying party during the setup phase, and therefore reaches the FIDO client as part of an HTTP response. Similarly, the response message that is processed by the relying party during the verification phase is sent by the FIDO Client to the relying party in an HTTP request. Beware the possibility of confusion when talking about requests and responses!

Request messages are created by the relying party and consumed by the U2F token. Response messages are created by the U2F token and consumed by the relying party.

As the messages flow from relying party (through the FIDO Client) to the U2F token and back, they undergo various transformations and encodings. Some of these transformations and encodings are up to the individual implementations and are not standardized as part of FIDO U2F. For example, FIDO U2F does not prescribe how request and response messages are encoded between the FIDO Client and the relying party.

However, to ensure that U2F tokens from different vendors can work across U2F-compliant web sites certain encodings are standardized:

  1. FIDO U2F standardizes a Javascript API that prescribes how a web application can pass request messages into the FIDO Client (in the case where the web browser is the FIDO Client), and what the encoding of the response messages is.

  2. FIDO U2F standardizes how request and response messages are to be encoded when sent over from the client over the USB, NFC, Bluetooth and Bluetooth Low-Energy transports to U2F tokens. In addition to specifying the encoding, the transport level specification also specifies the format for control messages to the tokens and the format for the error responses from the tokens.

In this document we describe the "raw", or canonical, format of the messages, i.e., without regard to the various encodings that are prescribed in U2F transport standards or that implementors might choose when sending messages around. The raw format of the messages is important to know for two reasons:

  1. The encoding of messages and parameters described elsewhere may refer to the raw messages described in this document. For example, a Javascript API might refer to a parameter of a function as the Base64-encoding of a raw registration response message. It is this document that describes what the raw registration response message looks like.

  2. Cryptographic signatures are calculated over raw data. For example, the standard might prescribe that a certain cryptographic signature is taken over bytes 5 through 60 of a certain raw message. The implementor therefore has to know how what the raw message looks like.

3. U2F message framing

The U2F protocol is based on a request-response mechanism, where a requester sends a request message to a U2F device, which always results in a response message being sent back from the U2F device to the requester.

The request message has to be "framed" to send to the lower layer. Taking the signature request as an example, the "framing" is a way for the FIDO client to tell the lower transport layer that it is sending a signature request and then send the raw message contents. The framing also specifies how the transport will carry back the response raw message and any meta-information such as an error code if the command failed.

Framing is defined based on the ISO7816-4:2005 APDU format.

3.1 Request Message Framing

The raw request message is framed as a command APDU. At a high level, APDUs are framed in the following way:

CLA INS P1 P2 [Lc <request-data>] [Le]


  • CLA: Reserved to be used by the underlying transport protocol (if applicable). The host application shall set this byte to zero.

  • INS: U2F command code, defined in the following sections.

  • P1, P2: Parameter 1 and 2, defined by each command.

  • Lc: The length of the request-data. If there are no request data bytes, Lc is omitted.

  • Le: The maximum expected length of the response data. If no response data are expected, Le may be omitted.

  • The precise format of the APDU depends on the encoding choice. There are two different encodings allowed for an APDU: short and extended length. The differences are in the way the length of the request data, Lc, and the maximum length of the expected response, Le, are encoded.

    The choice of encoding varies depending on the needs of the individual transport. Refer to the transport-specific encoding documents for which encodings are allowed with each transport.

    3.1.1 Command and parameter values


    3.1.2 Short Encoding

    In short encoding, the maximum length of request-data is 255 bytes. Lc is encoded in the following way:

    Let Nc = | <request-data> |. If Nc is 0, Lc is omitted. Otherwise, Lc is encoded as a single byte containing the value of Nc.

    If the instruction is not expected to yield any response bytes, Le may be omitted. Otherwise, in short encoding, Le is encoded in the following way:

    Let Ne = the maximum length of the response data. In short encoding, the maximum value of Ne is 256 bytes.

    For values of Ne between 1 and 255, Le contains the value of Ne. When Ne = 256, Le contains the value 0.

    3.1.3 Extended Length Encoding

    In extended length encoding, the maximum length of request-data is 65 535 bytes. Lc is encoded in the following way:

    Let Nc = | <request-data> |. If Nc is 0, Lc is omitted. Otherwise, Lc is encoded as:

    0 MSB(Nc) LSB(Nc)

    Where MSB(Nc) is the most significant byte of Nc, and LSB(Nc) is the least significant byte of Nc.

    In other words, the request-data are preceded by three length bytes, a byte with value 0 followed by the length of request-data, in big-endian order.

    If the instruction is not expected to yield any response bytes, Le may be omitted. Otherwise, in extended length encoding, Le is encoded in the following way:

    Let Ne = the maximum length of the response data. In extended length encoding, the maximum value of Ne is 65 536 bytes.

    For values of Ne between 1 and 65 535, inclusive, let Le1 = MSB(Ne), and Le2 = LSB(Ne), where MSB(Ne) is the most significant byte of Ne, and LSB(Ne) is the least significant byte of Ne.

    When Ne = 65 536, let Le1 = 0 and Le2 = 0.

    When Lc is present, i.e. if Nc > 0, Le is encoded as:

    Le1 Le2

    When Lc is absent, i.e. if Nc = 0, Le is encoded as:

    0 Le1 Le2

    In other words, Le has a single-byte prefix of 0 when Lc is absent.

    3.2 Response Message Framing

    The raw response data is framed as a response APDU:

    <response-data> SW1 SW2

    Where SW1 and SW2 are the status word bytes 1 and 2, respectively, forming a 16-bit status word, defined below. SW1 is the most-significant byte, and SW2 is the least-significant byte.

    3.3 Status Codes

    The following ISO7816-4 defined status words have a special meaning in U2F:

    Each implementation may define any other vendor-specific status codes, providing additional information about an error condition. Only the error codes listed above will be handled by U2F FIDO Client, where others will be seen as general errors and logging of these is optional.

    4. Registration Messages

    4.1 Registration Request Message - U2F_REGISTER

    Fig. 2 Registration Request Message

    This message is used to initiate a U2F token registration. The FIDO Client first contacts the relying party to obtain a challenge, and then constructs the registration request message. The registration request message has two parts:

    4.2 Registration Response Message: Error: Test-of-User-Presence Required

    This is an error message that is output by the U2F token if no test-of-user-presence could be obtained by the U2F token. The error message details are specified in the framing for the underlying transport (see Section "U2F Message Framing" above).

    4.3 Registration Response Message: Success

    Fig. 3 Registration Response Message

    This message is output by the U2F token once it created a new keypair in response to the registration request message. Note that U2F tokens SHOULD verify user presence before returning a registration response success message (otherwise they SHOULD return a test-of-user-presence-required message - see above). Its raw representation is the concatenation of the following:

    The signature is to be verified by the relying party using the public key certified in the attestation certificate. The relying party should also verify that the attestation certificate was issued by a trusted certification authority. The exact process of setting up trusted certification authorities is to be defined by the FIDO Alliance and is outside the scope of this document.

    Once the relying party verifies the signature, it should store the public key and key handle so that they can be used in future authentication operations.

    5. Authentication Messages

    5.1 Authentication Request Message - U2F_AUTHENTICATE

    Fig. 4 Authentication Request Message

    This message is used to initiate a U2F token authentication. The FIDO Client first contacts the relying party to obtain a challenge, and then constructs the authentication request message. The authentication request message has five parts:

    5.2 Authentication Response Message: Error: Test-of-User-Presence Required

    This is an error message that is output by the U2F token if no test-of-user-presence could be obtained by the U2F token. The error message details are specified in the framing for the underlying transport (see Section "U2F Message Framing" above).

    5.3 Authentication Response Message: Error: Bad Key Handle

    This is an error message that is output by the U2F token if the provided key handle was not originally created by this token, or if the provided key handle was created by this token, but for a different application parameter. The error message details are specified in the framing for the underlying transport (see Section "U2F Message Framing" above).

    5.4 Authentication Response Message: Success

    Fig. 5 Authentication Response Message: Success

    This message is output by the U2F token after processing/signing the authentication request message described above. Its raw representation is the concatenation of the following:

    6. Other Messages

    6.1 GetVersion Request and Response - U2F_VERSION

    The FIDO Client can query the U2F token about the U2F protocol version that it implements. The protocol version described in this document is U2F_V2.

    The response message's raw representation is the ASCII representation of the string 'U2F_V2' (without quotes, and without any NUL terminator).

    The command takes no flags, i.e. P1 and P2 are 0, and takes no data as input. As a result, the complete layout of this command in short encoding is, in hexadecimal form:

    CLA INS P1 P2 Le
    00 03 00 00 00

    The layout of this command in extended length encoding is, in hexadecimal form:

    CLA INS P1 P2 Le
    00 03 00 00 00 00 00

    6.2 Extensions and vendor-specific messages

    Command codes in the range between U2F_VENDOR_FIRST and U2F_VENDOR_LAST may be used for vendor-specific implementations. For example, the vendor may choose to put in some testing commands. Note that the FIDO client will never generate these commands. All other command codes are RFU and may not be used.

    7. Client Data


    websafe-base64 encoding

    This is the "Base 64 Encoding with URL and Filename Safe Alphabet" from Section 5 in [RFC4648] without padding.

    stringified javascript object

    This is the JSON object (i.e., a string starting with "{" and ending with "}") whose keys are the property names of the javascript object, and whose values are the corresponding property values. Only "data objects" can be stringified, i.e., only objects whose property names and values are supported in JSON.

    The registration and authentication request messages contain a challenge parameter, which is defined as the SHA-256 hash of a (UTF8 representation of a) stringified JSON data structure that the FIDO client has to prepare. The FIDO Client MUST send the Client Data (rather than its hash - the challenge parameter) to the relying party during the verification phase, where the relying party can re-generate the challenge parameter (by hashing the client data), which is necessary in order to verify the signature both on the registration response message and authentication response message.

    In the case where the FIDO Client is a web browser, the client data is defined as follows (in WebIDL):

    dictionary ClientData {
        DOMString             typ;
        DOMString             challenge;
        DOMString             origin;
        (DOMString or JwkKey) cid_pubkey;

    7.1 Dictionary ClientData Members

    typ of type DOMString
    the constant 'navigator.id.getAssertion' for authentication, and 'navigator.id.finishEnrollment' for registration
    challenge of type DOMString
    the websafe-base64-encoded challenge provided by the relying party
    origin of type DOMString
    the facet id of the caller, i.e., the web origin of the relying party.
    (Note: this might be more accurately called 'facet_id', but for compatibility with existing implementations within Chrome we keep the legacy name.)
    cid_pubkey of type (DOMString or JwkKey)
    The Channel ID public key used by this browser to communicate with the above origin. This parameter is optional, and missing if the browser doesn't support Channel ID. It is present and set to the constant 'unused' if the browser supports Channel ID, but is not using Channel ID to talk to the above origin (presumably because the origin server didn't signal support for the Channel ID TLS extension).

    Otherwise (i.e., both browser and origin server at the above origin support Channel ID), it is present and of type JwkKey.

    The JwkKey is a dictionary representing the public key used by a browser for the Channel ID TLS extension. The current version of the Channel ID draft prescribes the algorithm ([ECDSA-ANSI] in bibliography) and curve used, so the dictionary will have the following parameters

    dictionary JwkKey {
        DOMString kty;
        DOMString crv;
        DOMString x;
        DOMString y;

    7.2 Dictionary JwkKey Members

    kty of type DOMString
    signature algorithm used for Channel ID, i.e., the constant 'EC'
    crv of type DOMString
    Elliptic curve on which this public key is defined, i.e., the constant 'P-256'
    x of type DOMString
    websafe-base64-encoding of the x coordinate of the public key (big-endian, 32-byte value)
    y of type DOMString
    websafe-base64-encoding of the y coordinate of the public key (big-endian, 32-byte value)

    8. Examples

    8.1 Registration Example

    Assume we have a U2F token with the following private attestation key:


    the corresponding public key:


    and the following attestation cert:

    Version: V3
    Subject: CN=PilotGnubby-0.4.1-47901280001155957352 Signature Algorithm: SHA256withECDSA, OID = 1.2.840.10045.4.3.2

    Key: EC Public Key
    8d617e65c9508e64bcc5673ac82a6799da3c1446682c258c463fffdf58dfd2fa Y:

    Validity: [From: Tue Aug 14 11:29:32 PDT 2012, To: Wed Aug 14 11:29:32 PDT 2013]

    Issuer: CN=Gnubby Pilot
    SerialNumber: [ 47901280 00115595 7352] ]

    Algorithm: [SHA256withECDSA]
    0000: 30 44 02 20 60 CD B6 06 1E 9C 22 26 2D 1A AC 1D 0D. `....."&-...
    0010: 96 D8 C7 08 29 B2 36 65 31 DD A2 68 83 2C B8 36 ....).6e1..h.,.6
    0020: BC D3 0D FA 02 20 63 1B 14 59 F0 9E 63 30 05 57 ..... c..Y..c0.W
    0030: 22 C8 D8 9B 7F 48 88 3B 90 89 B8 8D 60 D1 D9 79 "....H.;....`..y
    0040: 59 02 B3 04 10 DF Y.....

    The attestation cert in hex form:


    Now let's assume that we use the following client data


    with hash:


    and application id:


    with hash:


    to construct a registration request message.

    Let's say the U2F token generates the following key pair:

    Private key:


    Public key:


    Associated key handle:


    The signature base string for the registration response message is therefore:


    A possible signature over the base string with the above private attestation key is:


    Which means the whole registration response message is:


    from which (together with challenge and application parameters) the signature base string and signature can be extracted, and verified with the public key from the attestation cert.

    8.2 Authentication Example

    Let's assume we have a U2F device with private key:


    and corresponding public key:


    Example application id:


    Example client data:


    Hash of the above client data (challenge parameter):


    Hash of the above application id (application parameter):


    Assuming counter = 1 and user_presence = 1, signature base string is:


    A possible signature with above private key is:


    Authentication Response Message:


    The above signature and signature base string can be reconstructed from the authentication response message and the challenge and application parameters, and can be verified with the above public key.

    9. Implementation Considerations

    Earlier revisions of the FIDO U2F specifications defined the U2F_VERSION command with the following byte layout:

    CL IN P1 P2 L0 L1 L2 Le
    00 03 00 00 00 00 00 00 00

    This is not compatible with ISO 7816-4. (Compatible encodings are defined earlier in this document.)

    For maximum compatibility with U2F Authenticators that followed the earlier specification for the U2F_VERSION command, U2F Clients may choose to support this older encoding over the HID protocol, the only protocol defined which used this encoding.

    A. References

    A.1 Normative references

    Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA), ANSI X9.62-2005. American National Standards Institute, November 2005, URL: http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62%3A2005
    ECMAScript Language Specification. URL: https://tc39.github.io/ecma262/
    D. Balfanz, B. Hill, R. Lindemann, D. Baghdasaryan, FIDO AppID and Facets v1.0. FIDO Alliance Proposed Standard. URLs:
    HTML: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-appid-and-facets-v1.2-ps-20170411.html
    PDF: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-appid-and-facets-v1.2-ps-20170411.pdf
    R. Lindemann, D. Baghdasaryan, B. Hill, J. Hodges, FIDO Technical Glossary. FIDO Alliance Implementation Draft. URLs:
    HTML: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-glossary-v1.2-ps-20170411.html
    PDF: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-glossary-v1.2-ps-20170411.pdf
    S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
    S. Josefsson, The Base16, Base32, and Base64 Data Encodings (RFC 4648), IETF, October 2006, URL: http://www.ietf.org/rfc/rfc4648.txt
    J. Ehrensvard, FIDO U2F HID Header Files v1.0. FIDO Alliance Review Draft (Work in progress.) URL: https://github.com/fido-alliance/u2f-specs/blob/master/inc/u2f.h
    Cameron McCormack; Boris Zbarsky; Tobie Langel. Web IDL. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/

    A.2 Informative references

    D. Balfanz, FIDO U2F Implementation Considerations v1.0. FIDO Alliance Review Draft (Work in progress.) URL: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-implementation-considerations-v1.2-ps-20170411.pdf
    S. Srinivas, D. Balfanz, E. Tiffany, FIDO U2F Overview v1.0. FIDO Alliance Review Draft (Work in progress.) URL: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.pdf