Smart Storage Battery Failure (battery 1 Service Information 0x0a)
Midas Souza
This specification describes an application layer protocol for communication between a roaming authenticator and another client/platform, as well as bindings of this application protocol to a variety of transport protocols using different physical media. The application layer protocol defines requirements for such transport protocols. Each transport binding defines the details of how such transport layer connections should be set up, in a manner that meets the requirements of the application layer protocol.
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 thelatest revision of this technical report can be found in the FIDO Alliance specifications index at
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 Membersand any other contributors to the Specification are not, and shall not be held, responsible in any mannerfor identifying or failing to identify any or all such third party intellectual property rights.
This protocol is intended to be used in scenarios where a user interactswith a Relying Party (a website or native app) on some platform (e.g., aPC) which prompts the user to interact with a roaming authenticator(e.g., a smartphone).
In order to provide evidence of user interaction, a roamingauthenticator implementing this protocol may have a built-in mechanismto obtain a "user gesture", allowing the platformto collect a PIN on behalf of the authenticator.
The CTAP1/U2F protocol, which is defined by the U2F Raw Messagesspecification [U2FRawMsgs]. CTAP1/U2F messages are recognizable by theirAPDU-like binary structure. CTAP1/U2F may also be referred to as CTAP 1.2or U2F 1.2. The latter was the U2F specification version used as the basisfor several portions of this specification. Authenticators implementingCTAP1/U2F are typically referred to as U2F authenticators or CTAP1authenticators.
The CTAP2 protocol, whose messages are encoded in the CTAP2 canonicalCBOR encoding form. Authenticators implementing CTAP2 are referred to asCTAP2 authenticators, FIDO2 authenticators, or WebAuthn authenticators.
Whole documents or specific features may be superseded by this document. A superseded document or feature MAY be implemented if optional, but it exists purely for backwards compatibility with older platforms or authenticators. Thus a superseded document or feature SHOULD NOT be used unless the replacement is not implemented by the counterparty. (Superseded features are not automatically optional, e.g. a CTAP 2.1 authenticator MUST still support authenticatorClientPIN's getPinToken subcommand if it supports clientPIN and CTAP 2.0.)
Occasionally, the term "CTAP" may be used without clarifying whether it isreferring to CTAP1 or CTAP2. In such cases, it should be understood to bereferring to the entirety of this specification or portions of thisspecification that are not specific to either CTAP1 or CTAP2. For example,some error messages begin with the term "CTAP" without clarifying whether theyare CTAP1- or CTAP2-specific because they are applicable to both CTAP protocolversions. CTAP protocol-specific error messages are prefixed with either"CTAP1" or "CTAP2" as appropriate.
The following data elements might be referenced by other specifications and hence should not be changed in their fundamental data type or high-level semantics without liaising with the other specifications:
aaguid, data type byte string and identifying the authenticator model, i.e. identical values mean that they refer to the same authenticator model and different values mean they refer to different authenticator models.
credentialID, data type byte string identifying a specific public key credential source, i.e. identical values mean that they refer to the same credential and different values mean they refer to different credentials. Note that there might be a very small probability that different credentials get assigned the same credentialID.
The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT","RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"in this specification are to be interpreted as described in [RFC2119].
Authenticator API: At this level of abstraction, each authenticator operation is defined similarly to an API call - it acceptsinput parameters and returns either an output or error code. Note that thisAPI level is conceptual and does not represent actual APIs. The actual APIswill be provided by each implementing platform.
Message Encoding: In order to invoke a method in theauthenticator API, the host must construct and encode a request and send itto the authenticator over the chosen transport protocol. The authenticatorwill then process the request and return an encoded response.
Transport-specific Binding: Requests and responses areconveyed to roaming authenticators over specific transports (e.g., USB, NFC,Bluetooth). For each transport technology, message bindings are specifiedfor this protocol.
The platform establishes a connection with a nominally appropriate available authenticator,having used criteria passed in by the Relying Party application and possibly other information it hasto select the authenticator.
Platform-mediated user interactions such as clientPin may provide user verification but are not considered to assert user presence. Thus, there are transport-based affordances affecting when and for how long user presence is established on a per-transport basis:
For example, in an authentication scenario, the user places an NFC authenticator on an NFC reading device having a keyboard and display, and is prompted to enter a PIN. If PIN entry is completed (e.g., by pressing Enter) before the NFC user presence maximum time limit expires, the authenticator will return an assertion with the "UP" bit in authenticator data set to true and the NFC userPresent flag is then set to false.
If a user lays an NFC authenticator on an NFC reader and for whatever reason ignores it for greater than the NFC user presence maximum time limit they will need to remove the authenticator from the NFC field and re-insert it and start over to complete any interaction requiring user presence.
In order to determine whether authenticatorMakeCredential's excludeList or authenticatorGetAssertion's allowList contain credential IDs that are already present on an authenticator, a platform typically invokes authenticatorGetAssertion with the "up" option key set to false and optionally pinUvAuthParam one or more times. If a credential is found an assertion is returned. If a valid pinUvAuthParam was also provided, the response will contain "up"=0 and "uv"=1 within the "flags bits" of the authenticator data structure, otherwise the "flag bits" will contain "up"=0 and "uv"=0.
Either or both clientPin or built-in user verification methods are supported and enabled.I.e., in the authenticatorGetInfo response the pinUvAuthToken option ID is present and set to true, and either clientPin option ID is present and set to true or uv option ID is present and set to true or both.
This refers to a timeout that occurs when the authenticator is waiting for direct action from the user, like a touch. (I.e. not a command from the platform.) The duration of this timeout is chosen by the authenticator but MUST be at least 10 seconds. Thirty seconds is a reasonable value.
Each operation in the authenticator API can be performed independently ofthe others, and all operations are asynchronous. The authenticator mayenforce a limit on outstanding operations to limit resource usage - inthis case, the authenticator is expected to return a busy status and thehost is expected to retry the operation later. Additionally, thisprotocol does not enforce in-order or reliable delivery of requests andresponses; if these properties are desired, they must be provided by theunderlying transport protocol or implemented at a higher layer byapplications.
Some commands or subcommands require the authenticator to maintain state. For example, the authenticatorCredentialManagement subcommand enumerateRPsGetNextRP implicitly assumes that the authenticator remembers which RP is next to return. The following (sub)commands require such state and are called stateful commands. Each such command uses and updates state that is initialized by a corresponding state initializing command:
An authenticator MUST discard the state for a stateful command command if the pinUvAuthToken that authenticated the state initializing command expires since the stateful commands do not themselves always verify a pinUvAuthToken.
This method is invoked by the host to request generation of a newcredential in the authenticator. It takes the following inputparameters, several of which correspond to those defined in the authenticatorMakeCredential operation section of the Web Authentication specification:
It contains an RP-specific user account identifier of type byte string, (optionally) a user name of type text string, (optionally) a user display name of type text string, and (optionally) a URL of type text string, referencing a user icon image (of a user avatar, for example). Note that while an empty account identifier is valid, it has known interoperability hurdles in practice and platforms are RECOMMENDED to avoid sending them.
If present with a valid value, the usual privacy concerns around attestation batching may not apply to the results of this operation and the platform is requesting an enterprise attestation that includes uniquely identifying information.
For example, if the authenticator is not protected by some form of user verification and user verification is required for the present usage scenario, e.g., the Relying Party set options.authenticatorSelection.userVerification to "required" in the WebAuthn API, then the platform recovers in some fashion out of scope of these actions.
c80f0f1006