Type names, attribute names and element names are written as
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]].
UAF specific terminology used in this document is defined in [[!FIDOGlossary]].
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]].
The general protocol between a FIDO client and authenticator over NFC is as follows:
The NFC protocol SHALL NOT use any additional framing (unlike the USB HID protocol, for example). Instead, messages sent to an NFC authenticator SHALL follow the U2F raw message format as defined in [U2FRAWMESSAGES] in the bibliography.
Some responses may not fit into a short APDU, for this reason U2F authenticators MUST respond in the following way:
A FIDO client SHALL always send an applet selection command to begin interaction with a FIDO authenticator via NFC. The structure of the applection command SHALL follow the same APDU structure as in the raw message format mentioned above.
The FIDO U2F AID consists of the following fields:
As a result, the command for selecting the applet using the FIDO U2F AID is:
In response to the applet selection command, the FIDO authenticator SHALL reply with its version string in the successful response. In this writing, the version string is "U2F_V2", hence a successful response to the applet selection command would consist of the following bytes:
Some NFC authenticators may be passively powered -- drawing all of their power from the NFC field. If the authenticator does not power up quick enough or has insufficient power, a poor user experience is likely to occur.
[U2FRAWMESSAGES] Dirk Balfanz, Jakob Ehrensvard. FIDO U2F Raw Message Formats, Aug 2014