## Abstract

The goal of the Universal Authentication Framework is to provide a unified and extensible authentication mechanism that supplants passwords while avoiding the shortcomings of current alternative authentication approaches.

This approach is designed to allow the relying party to choose the best available authentication mechanism for a particular end user or interaction, while preserving the option to leverage emerging device security capabilities in the future without requiring additional integration effort.

This document describes the FIDO architecture in detail, it defines the flow and content of all UAF protocol messages and presents the rationale behind the design choices.

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

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.

The notation base64url refers to "Base 64 Encoding with URL and Filename Safe Alphabet" [RFC4648] without padding.

Following [WebIDL-ED], dictionary members are optional unless they are explicitly marked as `required`.

WebIDL dictionary members MUST NOT have a value of null — i.e., there are no declarations of nullable dictionary members in this specification.

Unless otherwise specified, if a WebIDL dictionary member is DOMString, it MUST NOT be empty.

Unless otherwise specified, if a WebIDL dictionary member is a List, it MUST NOT be an empty list.

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

All diagrams, examples, notes in this specification are non-normative.

Note

Note: Certain dictionary members need to be present in order to comply with FIDO requirements. Such members are marked in the WebIDL definitions found in this document, as `required`. The keyword `required` has been introduced by [WebIDL-ED], which is a work-in-progress. If you are using a WebIDL parser which implements [WebIDL], then you may remove the keyword `required` from your WebIDL and use other means to ensure those fields are present.

### 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. Overview

This section is non-normative.

The goal of this Universal Authentication Framework is to provide a unified and extensible authentication mechanism that supplants passwords while avoiding the shortcomings of current alternative authentication approaches.

The design goal of the protocol is to enable Relying Parties to leverage the diverse and heterogeneous set of security capabilities available on end users' devices via a single, unified protocol.

This approach is designed to allow the FIDO Relying Parties to choose the best available authentication mechanism for a particular end user or interaction, while preserving the option for a relying party to leverage emerging device security capabilities in the future, without requiring additional integration effort.

### 2.1 Scope

This document describes FIDO architecture in detail and defines the UAF protocol as a network protocol. It defines the flow and content of all UAF messages and presents the rationale behind the design choices.

Particular application-level bindings are outside the scope of this document. This document is not intended to answer questions such as:

- What does an HTTP binding look like for UAF?
- How can a web application communicate to FIDO UAF Client?
- How can FIDO UAF Client communicate to FIDO enabled Authenticators?

The answers to these questions can be found in other UAF specifications, e.g. [UAFAppAPIAndTransport] [UAFASM] [UAFAuthnrCommands].

### 2.2 Architecture

The following diagram depicts the entities involved in UAF protocol.

Fig. 1 The UAF Architecture

Of these entities, only these three directly create and/or process UAF protocol messages:

- FIDO Server, running on the relying party's infrastructure
- FIDO UAF Client, part of the user agent and running on the FIDO user device
- FIDO Authenticator, integrated into the FIDO user device

It is assumed in this document that a FIDO Server has access to the UAF Authenticator Metadata [FIDOMetadataStatement] describing all the authenticators it will interact with.

### 2.3 Protocol Conversation

The core UAF protocol consists of four conceptual conversations between a FIDO UAF Client and FIDO Server.

- Registration: UAF allows the relying party to register a FIDO Authenticator with the user's account at the relying party. The relying party can specify a policy for supporting various FIDO Authenticator types. A FIDO UAF Client will only register existing authenticators in accordance with that policy.

- Authentication: UAF allows the relying party to prompt the end user to authenticate using a previously registered FIDO Authenticator. This authentication can be invoked any time, at the relying party's discretion.

- Transaction Confirmation: In addition to providing a general authentication prompt, UAF offers support for prompting the user to confirm a specific transaction.

  This prompt includes the ability to communicate additional information to the client for display to the end user, using the client's transaction confirmation display. The goal of this additional authentication operation is to enable relying parties to ensure that the user is confirming a specified set of the transaction details (instead of authenticating a session to the user agent).

- Deregistration: The relying party can trigger the deletion of the account-related authentication key material.

Although this document defines the FIDO Server as the initiator of requests, in a real world deployment the first UAF operation will always follow a user agent's (e.g. HTTP) request to a relying party.

The following sections give a brief overview of the protocol conversation for individual operations. More detailed descriptions can be found in the sections Registration Operation, Authentication Operation, and Deregistration Operation.

#### 2.3.1 Registration

The following diagram shows the message flows for registration.

Fig. 2 UAF Registration Message Flow
Note

The client application should use the appropriate API to inform the FIDO UAF Client of the results of the operation (see section 2.3.1 in [UAFAppAPIAndTransport]) in order to allow the FIDO UAF Client to do some "housekeeping" tasks.

#### 2.3.2 Authentication

The following diagram depicts the message flows for the authentication operation.

Fig. 3 Authentication Message Flow
Note

The client application should use the appropriate API to inform the FIDO UAF Client of the results of the operation (see section 2.3.1 in [UAFAppAPIAndTransport]) in order to allow FIDO UAF Client to do some "housekeeping" tasks.

#### 2.3.3 Transaction Confirmation

The following figure depicts the transaction confirmation message flow.

Fig. 4 Transaction Confirmation Message Flow
Note

The client application should use the appropriate API to inform the FIDO UAF Client of the results of the operation (see section 2.3.1 in [UAFAppAPIAndTransport]) in order to allow the FIDO UAF Client to do some "housekeeping" tasks.

#### 2.3.4 Deregistration

The following diagram depicts the deregistration message flow.

Fig. 5 Deregistration Message Flow
Note

The client application should use the appropriate API to inform the FIDO UAF Client of the results of the operation (see section 2.3.1 in [UAFAppAPIAndTransport]) in order to allow the FIDO UAF Client to do some "housekeeping" tasks.

## 3. Protocol Details

This section is normative.

This section provides a detailed description of operations supported by the UAF Protocol.

Support of all protocol elements is mandatory for conforming software, unless stated otherwise.

All string literals in this specification are constructed from Unicode codepoints within the set `U+0000`..`U+007F`.

Unless otherwise specified, protocol messages are transferred with a UTF-8 content encoding.

Note

All data used in this protocol must be exchanged using a secure transport protocol (such as TLS/HTTPS) established between the FIDO UAF Client and the relying party in order to follow the assumptions made in [FIDOSecRef]; details are specified in section 4.1.7 TLS Protected Communication.

The notation `base64url(byte[8..64])` reads as 8-64 bytes of data encoded in base64url, "Base 64 Encoding with URL and Filename Safe Alphabet" [RFC4648] without padding.

The notation `string[5]` reads as five unicode characters, represented as a UTF-8 [RFC3629] encoded string of the type indicated in the declaration, typically a WebIDL [WebIDL-ED] DOMString.

As the UTF-8 representation has variable length, the maximum byte length of `string[5]` is `string[4*5]`.

All strings are case-sensitive unless stated otherwise.

This document uses WebIDL [WebIDL-ED] to define UAF protocol messages.

Implementations MUST serialize the UAF protocol messages for transmission using UTF-8 encoded JSON [RFC4627].

### 3.1 Shared Structures and Types

This section defines types and structures shared by various operations.

#### 3.1.1 Version Interface

Represents a generic version with major and minor fields.

    interface Version {
        readonly    attribute unsigned short major;
        readonly    attribute unsigned short minor;
    };

##### 3.1.1.1 Attributes

`major` of type unsigned short, readonly
  Major version.
`minor` of type unsigned short, readonly
  Minor version.

#### 3.1.2 Operation enumeration

Describes the operation type of a UAF message or request for a message.

    enum Operation {
        "Reg",
        "Auth",
        "Dereg"
    };

Enumeration description
`Reg` | Registration
`Auth` | Authentication or Transaction Confirmation
`Dereg` | Deregistration

#### 3.1.3 OperationHeader dictionary

Represents a UAF message Request and Response header

    dictionary OperationHeader {
        required Version   upv;
        required Operation op;
        DOMString          appID;
        DOMString          serverData;
        Extension[]        exts;
    };

##### 3.1.3.1 Dictionary `OperationHeader` Members

`upv` of type required Version
  UAF protocol version (`upv`). To conform with this version of the UAF spec set, the `major` value MUST be `1` and the `minor` value MUST be `1`.
`op` of type required Operation
  Name of FIDO operation (`op`) this message relates to.
  Note

  "Auth" is used for both authentication and transaction confirmation.

`appID` of type DOMString
  `string[0..512]`.

  The application identifier that the relying party would like to assert.

  There are three ways to set the `AppID` [FIDOAppIDAndFacets]:

  1. If the element is missing or empty in the request, the FIDO UAF Client MUST set it to the `FacetID` of the caller.
  2. If the `appID` present in the message is identical to the `FacetID` of the caller, the FIDO UAF Client MUST accept it.
  3. If it is an URI with HTTPS protocol scheme, the FIDO UAF Client MUST use it to load the list of trusted facet identifiers from the specified URI. The FIDO UAF Client MUST only accept the request, if the facet identifier of the caller matches one of the trusted facet identifiers in the list returned from dereferencing this URI.
  Note

  The new key pair that the authenticator generates will be associated with this application identifier.

  Security Relevance: The application identifier is used by the FIDO UAF Client to verify the eligibility of an application to trigger the use of a specific `UAuth.Key`. See [FIDOAppIDAndFacets]

`serverData` of type DOMString
  `string[1..1536]`.

  A session identifier created by the relying party.

  Note
  The relying party can opaquely store things like expiration times for the registration session, protocol version used and other useful information in `serverData`. This data is opaque to FIDO UAF Clients. FIDO Servers may reject a response that is lacking this data or is containing unauthorized modifications to it.

  Servers that depend on the integrity of `serverData` should apply appropriate security measures, as described in Registration Request Generation Rules for FIDO Server and section ServerData and KeyHandle.

`exts` of type array of `Extension`
  List of UAF Message Extensions.

#### 3.1.4 Authenticator Attestation ID (AAID) typedef

    typedef DOMString AAID;

`string[9]`

Each authenticator MUST have an `AAID` to identify UAF enabled authenticator models globally. The `AAID` MUST uniquely identify a specific authenticator model within the range of all UAF-enabled authenticator models made by all authenticator vendors, where authenticators of a specific model must share identical security characteristics within the model (see Security Considerations).

The `AAID` is a string with format "V#M", where

"#" is a separator

"V" indicates the authenticator Vendor Code. This code consists of 4 hexadecimal digits.

"M" indicates the authenticator Model Code. This code consists of 4 hexadecimal digits.

The Augmented BNF [ABNF] for the `AAID` is:

AAID = 4(HEXDIG) "#" 4(HEXDIG)

Note

HEXDIG is case insensitive, i.e. "03EF" and "03ef" are identical.

The FIDO Alliance is responsible for assigning authenticator vendor Codes.

Authenticator vendors are responsible for assigning authenticator model codes to their authenticators. Authenticator vendors MUST assign unique `AAIDs` to authenticators with different security characteristics.

AAIDs are unique and each of them must relate to a distinct authentication metadata file ([FIDOMetadataStatement])

Note

Adding new firmware/software features, or changing the underlying hardware protection mechanisms will typically change the security characteristics of an authenticator and hence would require a new `AAID` to be used. Refer to ([FIDOMetadataStatement]) for more details.

#### 3.1.5 KeyID typedef

    typedef DOMString KeyID;

`base64url(byte[32...2048])`

`KeyID` is a unique identifier (within the scope of an `AAID`) used to refer to a specific `UAuth.Key`. It is generated by the authenticator and registered with a FIDO Server.

The (`AAID`, `KeyID` ) tuple MUST uniquely identify an authenticator's registration for a relying party. Whenever a FIDO Server wants to provide specific information to a particular authenticator it MUST use the (`AAID`, `KeyID`) tuple.

`KeyID` MUST be base64url encoded within the UAF message (see above).

During step-up authentication and deregistration operations, the FIDO Server SHOULD provide the `KeyID` back to the authenticator for the latter to locate the appropriate user authentication key, and perform the necessary operation with it.

Roaming authenticators which don't have internal storage for, and cannot rely on any ASM to store, generated key handles SHOULD provide the key handle as part of the `AuthenticatorRegistrationAssertion.assertion.KeyID` during the registration operation (see also section ServerData and KeyHandle) and get the key handle back from the FIDO Server during the step-up authentication (in the `MatchCriteria` dictionary which is part of the policy) or deregistration operations (see [UAFAuthnrCommands] for more details).

Note

The exact structure and content of a `KeyID` is specific to the authenticator implementation.

#### 3.1.6 ServerChallenge typedef

    typedef DOMString ServerChallenge;

`base64url(byte[8...64])`

`ServerChallenge` is a server-provided random challenge. Security Relevance: The challenge is used by the FIDO Server to verify whether an incoming response is new, or has already been processed. See section Replay Attack Protection for more details.

The `ServerChallenge` SHOULD be mixed into the entropy pool of the authenticator. Security Relevance: The FIDO Server SHOULD provide a challenge containing strong cryptographic randomness whenever possible. See section Server Challenge and Random Numbers.

Note

The minimum challenge length of 8 bytes follows the requirement in [SP800-63] and is equivalent to the 20 decimal digits as required in [RFC6287].

Note

The maximum length has been defined such that SHA-512 output can be used without truncation.

Note

The mixing of multiple sources of randomness is recommended to improve the quality of the random numbers generated by the authenticator, as described in [RFC4086].

#### 3.1.7 FinalChallengeParams dictionary

    dictionary FinalChallengeParams {
        required DOMString       appID;
        required ServerChallenge challenge;
        required DOMString       facetID;
        required ChannelBinding  channelBinding;
    };

##### 3.1.7.1 Dictionary `FinalChallengeParams` Members

`appID` of type required DOMString
  `string[1..512]`

  The value MUST be taken from the `appID` field of the `OperationHeader`

`challenge` of type required ServerChallenge

  The value MUST be taken from the challenge field of the request (e.g. RegistrationRequest.challenge, AuthenticationRequest.challenge).

`facetID` of type required DOMString
  `string[1..512]`

  The value is determined by the FIDO UAF Client and it depends on the calling application. See [FIDOAppIDAndFacets] for more details. Security Relevance: The `facetID` is determined by the FIDO UAF Client and verified against the list of trusted facets retrieved by dereferencing the `appID` of the calling application.

`channelBinding` of type required ChannelBinding

  Contains the TLS information to be sent by the FIDO Client to the FIDO Server, binding the TLS channel to the FIDO operation.

#### 3.1.8 TLS ChannelBinding dictionary

ChannelBinding contains channel binding information [RFC5056].

Note

Security Relevance:The channel binding may be verified by the FIDO Server in order to detect and prevent MITM attacks.

At this time, the following channel binding methods are supported:

- TLS ChannelID (`cid_pubkey`) [ChannelID]
- serverEndPoint [RFC5929]
- tlsServerCertificate
- tlsUnique [RFC5929]

Further requirements:

1. If data related to any of the channel binding methods, described here, is available to the FIDO UAF Client (i.e. included in this dictionary), it MUST be used according to the relevant specification .
2. All channel binding methods described here MUST be supported by the FIDO Server. The FIDO Server MAY reject operations if the channel binding cannot be verified successfully.

Note

- If channel binding data is accessible to the web browser or client application, it must be relayed to the FIDO UAF Client in order to follow the assumptions made in [FIDOSecRef].
- If channel binding data is accessible to the web server, it must be relayed to the FIDO Server in order to follow the assumptions made in [FIDOSecRef]. The FIDO Server relies on the web server to provide accurate channel binding information.

    dictionary ChannelBinding {
        DOMString serverEndPoint;
        DOMString tlsServerCertificate;
        DOMString tlsUnique;
        DOMString cid_pubkey;
    };

##### 3.1.8.1 Dictionary `ChannelBinding` Members

`serverEndPoint` of type DOMString

  The field `serverEndPoint` MUST be set to the base64url-encoded hash of the TLS server certificate if this is available. The hash function MUST be selected as follows:

  1. if the certificate's `signatureAlgorithm` uses a single hash function and that hash function is either MD5 [RFC1321] or SHA-1 [RFC6234], then use SHA-256 [FIPS180-4];
  2. if the certificate's `signatureAlgorithm` uses a single hash function and that hash function is neither MD5 nor SHA-1, then use the hash function associated with the certificate's`signatureAlgorithm`;
  3. if the certificate's `signatureAlgorithm` uses no hash functions, or uses multiple hash functions, then this channel binding type's channel bindings are undefined at this time (updates to this channel binding type may occur to address this issue if it ever arises)

  This field MUST be absent if the TLS server certificate is not available to the processing entity (e.g., the FIDO UAF Client) or the hash function cannot be determined as described.

`tlsServerCertificate` of type DOMString

  This field MUST be absent if the TLS server certificate is not available to the FIDO UAF Client.

  This field MUST be set to the base64url-encoded, DER-encoded TLS server certificate, if this data is available to the FIDO UAF Client.

`tlsUnique` of type DOMString
  MUST be set to the base64url-encoded TLS channel `Finished` structure. It MUST, however, be absent, if this data is not available to the FIDO UAF Client [RFC5929].

  The use of the tlsUnique is deprecated as the security of the `tls-unqiue` channel binding type [RFC5929] is broken, see [TLSAUTH].

`cid_pubkey` of type DOMString

  MUST be absent if the client TLS stack doesn't provide TLS ChannelID [ChannelID] information to the processing entity (e.g., the web browser or client application).

  MUST be set to "unused" if TLS ChannelID information is supported by the client-side TLS stack but has not been signaled by the TLS (web) server.

  Otherwise, it MUST be set to the base64url-encoded serialized [RFC4627] `JwkKey` structure using UTF-8 encoding.

#### 3.1.9 JwkKey dictionary

`JwkKey` is a dictionary representing a JSON Web Key encoding of an elliptic curve public key [JWK].

This public key is the ChannelID public key minted by the client TLS stack for the particular relying party. [ChannelID] stipulates using only a particular elliptic curve, and the particular coordinate type.

    dictionary JwkKey {
        required DOMString kty = "EC";
        required DOMString crv = "P-256";
        required DOMString x;
        required DOMString y;
    };

##### 3.1.9.1 Dictionary `JwkKey` Members

`kty` of type required DOMString, defaulting to `"EC"`
  Denotes the key type used for Channel ID. At this time only elliptic curve is supported by [ChannelID], so it MUST be set to "EC" [JWA].
`crv` of type required DOMString, defaulting to `"P-256"`
  Denotes the elliptic curve on which this public key is defined. At this time only the NIST curve `secp256r1` is supported by [ChannelID], so the `crv` parameter MUST be set to "P-256".
`x` of type required DOMString
  Contains the base64url-encoding of the x coordinate of the public key (big-endian, 32-byte value).
`y` of type required DOMString
  Contains the base64url-encoding of the y coordinate of the public key (big-endian, 32-byte value).

#### 3.1.10 Extension dictionary

FIDO extensions can appear in several places, including the UAF protocol messages, authenticator commands, or in the assertion signed by the authenticator.

Each extension has an identifier, and the namespace for extension identifiers is FIDO UAF global (i.e. doesn't depend on the message where the extension is present).

Extensions can be defined in a way such that a processing entity which doesn't understand the meaning of a specific extension MUST abort processing, or they can be specified in a way that unknown extension can (safely) be ignored.

Extension processing rules are defined in each section where extensions are allowed.

Generic extensions used in various operations.

    dictionary Extension {
        required DOMString id;
        required DOMString data;
        required boolean   fail_if_unknown;
    };

##### 3.1.10.1 Dictionary `Extension` Members

`id` of type required DOMString
  `string[1..32]`.

  Identifies the extension.

`data` of type required DOMString
  Contains arbitrary data with a semantics agreed between server and client. Binary data is base64url-encoded.

  This field MAY be empty.

`fail_if_unknown` of type required boolean
  Indicates whether unknown extensions must be ignored (`false`) or must lead to an error (`true`).
  - A value of `false` indicates that unknown extensions MUST be ignored
  - A value of `true` indicates that unknown extensions MUST result in an error.

Note

The FIDO UAF Client might (a) process an extension or (b) pass the extension through to the ASM. Unknown extensions must be passed through.

The ASM might (a) process an extension or (b) pass the extension through to the FIDO authenticator. Unknown extensions must be passed through.

The FIDO authenticator must handle the extension or ignore it (only if it doesn't know how to handle it and `fail_if_unknown` is not set). If the FIDO authenticator doesn't understand the meaning of the extension and `fail_if_unknown` is set, it must generate an error (see definition of `fail_if_unknown` above).

When passing through an extension to the next entity, the `fail_if_unknown` flag must be preserved (see [UAFASM] [UAFAuthnrCommands]).

FIDO protocol messages are not signed. If the security depends on an extension being known or processed, then such extension should be accompanied by a related (and signed) extension in the authenticator assertion (e.g. `TAG_UAFV1_REG_ASSERTION`, `TAG_UAFV1_AUTH_ASSERTION`). If the security has been increased (e.g. the FIDO authenticator according to the description in the metadata statement accepts multiple fingers but in this specific case indicates that the finger used at registration was also used for authentication) there is no need to mark the extension as `fail_if_unknown` (i.e. tag 0x3E12 should be used [UAFAuthnrCommands]). If the security has been degraded (e.g. the FIDO authenticator according to the description in the metadata statement accepts only the finger used at registration for authentication but in this specific case indicates that a different finger was used for authentication) the extension must be marked as `fail_if_unknown` (i.e. tag 0x3E11 must be used [UAFAuthnrCommands]).

#### 3.1.11 MatchCriteria dictionary

Represents the matching criteria to be used in the server policy.

The `MatchCriteria` object is considered to match an authenticator, if all fields in the object are considered to match (as indicated in the particular fields).

    dictionary MatchCriteria {
        AAID[]           aaid;
        DOMString[]      vendorID;
        KeyID[]          keyIDs;
        unsigned long    userVerification;
        unsigned short   keyProtection;
        unsigned short   matcherProtection;
        unsigned long    attachmentHint;
        unsigned short   tcDisplay;
        unsigned short[] authenticationAlgorithms;
        DOMString[]      assertionSchemes;
        unsigned short[] attestationTypes;
        unsigned short   authenticatorVersion;
        Extension[]      exts;
    };

##### 3.1.11.1 Dictionary `MatchCriteria` Members

`aaid` of type array of `AAID`
  List of AAIDs, causing matching to be restricted to certain AAIDs.

  The field `m.aaid` MAY be combined with (one or more of) `m.keyIDs`, `m.attachmentHint`, `m.authenticatorVersion`, and `m.exts`, but `m.aaid` MUST NOT be combined with any other match criteria field.

  If `m.aaid` is not provided - at least `m.authenticationAlgorithms` and `m.assertionSchemes` MUST be provided.

  The match succeeds if at least one AAID entry in this array matches `AuthenticatorInfo.aaid` [UAFASM].

  Note

  This field corresponds to `MetadataStatement.aaid` [FIDOMetadataStatement].

`vendorID` of type array of DOMString
  The vendorID causing matching to be restricted to authenticator models of the given vendor. The first 4 characters of the AAID are the vendorID (see `AAID`)).

  The match succeeds if at least one entry in this array matches the first 4 characters of the `AuthenticatorInfo.aaid` [UAFASM].

  Note

  This field corresponds to the first 4 characters of `MetadataStatement.aaid` [FIDOMetadataStatement].

`keyIDs` of type array of `KeyID`
  A list of authenticator KeyIDs causing matching to be restricted to a given set of `KeyID` instances. (see TAG_KEYID in [UAFRegistry]).

  This match succeeds if at least one entry in this array matches.

  Note

  This field corresponds to `AppRegistration.keyIDs` [UAFASM].

`userVerification` of type unsigned long
  A set of 32 bit flags which may be set if matching should be restricted by the user verification method (see [FIDORegistry]).
  Note
  The match with `AuthenticatorInfo.userVerification` ([UAFASM]) succeeds, if the following condition holds (written in Java):

      if (
              // They are equal
              (AuthenticatorInfo.userVerification == MatchCriteria.userVerification) ||

              // USER_VERIFY_ALL is not set in both of them and they have at least one common bit set
              (
                  ((AuthenticatorInfo.userVerification & USER_VERIFY_ALL) == 0) &&
                  ((MatchCriteria.userVerification & USER_VERIFY_ALL) == 0) &&
                  ((AuthenticatorInfo.userVerification & MatchCriteria.userVerification) != 0)
              )
         )

  Note
  This field value can be derived from `MetadataStatement.userVerificationDetails` as follows:
  1. if `MetadataStatement.userVerificationDetails` contains multiple entries, then:
     1. if one or more entries `MetadataStatement.userVerificationDetails[i]` contain multiple entries, then: stop, direct derivation is not possible. Must generate `MatchCriteria` object by providing a list of matching AAIDs.
     2. if all entries `MetadataStatement.userVerificationDetails[i]` only contain a single entry, then: combine all entries `MetadataStatement.userVerificationDetails[0][0].userVerification` to `MetadataStatement.userVerificationDetails[N-1][0].userVerification` into a single value using a bitwise OR operation.
  2. if `MetadataStatement.userVerificationDetails` contains a single entry, then: combine all entries `MetadataStatement.userVerificationDetails[0][0].userVerification` to `MetadataStatement.userVerificationDetails[0][N-1].userVerification` into a single value using a bitwise OR operation and (if multiple bit flags have been set) additionally set the flag `USER_VERIFY_ALL`.

  This method doesn't allow matching authenticators implementing complex combinations of user verification methods, such as `PIN AND (Fingerprint OR Speaker Recognition)` (see above derivation rules). If such specific match rules are required, they need to be specified by providing the AAIDs of the matching authenticators.

`keyProtection` of type unsigned short
  A set of 16 bit flags which may be set if matching should be restricted by the key protections used (see [FIDORegistry]).

  This match succeeds, if at least one of the bit flags matches the value of `AuthenticatorInfo.keyProtection` [UAFASM].

  Note

  This field corresponds to `MetadataStatement.keyProtection` [FIDOMetadataStatement].

`matcherProtection` of type unsigned short
  A set of 16 bit flags which may be set if matching should be restricted by the matcher protection (see [FIDORegistry]).

  The match succeeds if at least one of the bit flags matches the value of `AuthenticatorInfo.matcherProtection` [UAFASM].

  Note

  This field corresponds to the `MetadataStatement.matcherProtection` metadata statement. See [FIDOMetadataStatement].

`attachmentHint` of type unsigned long
  A set of 32 bit flags which may be set if matching should be restricted by the authenticator attachment mechanism (see [FIDORegistry]).

  This field is considered to match, if at least one of the bit flags matches the value of `AuthenticatorInfo.attachmentHint` [UAFASM].

  Note

  This field corresponds to the `MetadataStatement.attachmentHint` metadata statement.

`tcDisplay` of type unsigned short
  A set of 16 bit flags which may be set if matching should be restricted by the transaction confirmation display availability and type. (see [FIDORegistry]).

  This match succeeds if at least one of the bit flags matches the value of `AuthenticatorInfo.tcDisplay` [UAFASM].

  Note

  This field corresponds to the `MetadataStatement.tcDisplay` metadata statement. See [FIDOMetadataStatement].

`authenticationAlgorithms` of type array of unsigned short
  An array containing values of supported authentication algorithm TAG values (see [FIDORegistry], prefix `ALG_SIGN`) if matching should be restricted by the supported authentication algorithms. This field MUST be present, if field `aaid` is missing.

  This match succeeds if at least one entry in this array matches the `AuthenticatorInfo.authenticationAlgorithm` [UAFASM].

  Note

  This field corresponds to the `MetadataStatement.authenticationAlgorithm` metadata statement. See [FIDOMetadataStatement].

`assertionSchemes` of type array of DOMString
  A list of supported assertion schemes if matching should be restricted by the supported schemes. This field MUST be present, if field `aaid` is missing.

  See section UAF Supported Assertion Schemes for details.

  This match succeeds if at least one entry in this array matches `AuthenticatorInfo.assertionScheme` [UAFASM].

  Note

  This field corresponds to the `MetadataStatement.assertionScheme` metadata statement. See [FIDOMetadataStatement].

`attestationTypes` of type array of unsigned short
  An array containing the preferred attestation TAG values (see [UAFRegistry], prefix `TAG_ATTESTATION`). The order of items MUST be preserved. The most-preferred attestation type comes first.

  This match succeeds if at least one entry in this array matches one entry in `AuthenticatorInfo.attestationTypes` [UAFASM].

  Note

  This field corresponds to the `MetadataStatement.attestationTypes` metadata statement. See [FIDOMetadataStatement].

`authenticatorVersion` of type unsigned short
  Contains an authenticator version number, if matching should be restricted by the authenticator version in use.

  This match succeeds if the value is lower or equal to the field `AuthenticatorVersion` included in `TAG_UAFV1_REG_ASSERTION` or `TAG_UAFV1_AUTH_ASSERTION` or a corresponding value in the case of a different assertion scheme.

  Note

  Since the semantic of the `authenticatorVersion` depends on the AAID, the field `authenticatorVersion` should always be combined with a single `aaid` in `MatchCriteria`.

  This field corresponds to the `MetadataStatement.authenticatorVersion` metadata statement. See [FIDOMetadataStatement].

  The use of authenticatorVersion in the policy is deprecated since there is no standardized way for the FIDO Client to learn the authenticatorVersion. The authenticatorVersion is included in the auhentication assertion and hence can still be evaluated in the FIDO Server.

`exts` of type array of `Extension`
  Extensions for matching policy.

#### 3.1.12 Policy dictionary

Contains a specification of accepted authenticators and a specification of disallowed authenticators.

    dictionary Policy {
        required MatchCriteria[][] accepted;
        MatchCriteria[]            disallowed;
    };

##### 3.1.12.1 Dictionary `Policy` Members

`accepted` of type array of array of required MatchCriteria

  This field is a two-dimensional array describing the required authenticator characteristics for the server to accept either a FIDO registration, or authentication operation for a particular purpose.

  This two-dimensional array can be seen as a list of sets. List elements (i.e. the sets) are alternatives (OR condition).

  All elements within a set MUST be combined:

  The first array index indicates OR conditions (i.e. the list). Any set of authenticator(s) satisfying these `MatchCriteria` in the first index is acceptable to the server for this operation.

  Sub-arrays of MatchCriteria in the second index (i.e. the set) indicate that multiple authenticators (i.e. each set element) MUST be registered or authenticated to be accepted by the server.

  The MatchCriteria array represents ordered preferences by the server. Servers MUST put their preferred authenticators first, and FIDO UAF Clients SHOULD respect those preferences, either by presenting authenticator options to the user in the same order, or by offering to perform the operation using only the highest-preference authenticator(s).

  Note
  This list MUST NOT be empty. If the FIDO Server accepts any authenticator, it can follow the example below.
  Example 1: Example for an 'any' policy

      {
        "accepted":
        [
      	[{ "userVerification": 1023 }]
        ]
      }

  Note

  1023 = 0x3ff = USER_VERIFY_PRESENCE | USER_VERIFY_FINGERPRINT | ... | USER_VERIFY_NONE

`disallowed` of type array of `MatchCriteria`
  Any authenticator that matches any of MatchCriteria contained in the field disallowed MUST be excluded from eligibility for the operation, regardless of whether it matches any MatchCriteria present in the `accepted` list, or not.

### 3.2 Processing Rules for the Server Policy

This section is normative.

The FIDO UAF Client MUST follow the following rules while parsing server policy:

1. During registration:
   1. `Policy.accepted` is a list of combinations. Each combination indicates a list of criteria for authenticators that the server wants the user to register.
   2. Follow the priority of items in `Policy.accepted[][]`. The lists are ordered with highest priority first.
   3. Choose the combination whose criteria best match the features of the currently available authenticators
   4. Collect information about available authenticators
   5. Ignore authenticators which match the `Policy.disallowed` criteria
   6. Match collected information with the matching criteria imposed in the policy (see MatchCriteria dictionary for more details on matching)
   7. Guide the user to register the authenticators specified in the chosen combination
2. During authentication and transaction confirmation:
   Note

   `Policy.accepted` is a list of combinations. Each combination indicates a set of criteria which is enough to completely authenticate the current pending operation

   1. Follow the priority of items in `Policy.accepted[][]`. The lists are ordered with highest priority first.
   2. Choose the combination whose criteria best match the features of the currently available authenticators
   3. Collect information about available authenticators
   4. Ignore authenticators which meet the `Policy.disallowed` criteria
   5. Match collected information with the matching criteria described in the policy
   6. Guide the user to authenticate with the authenticators specified in the chosen combination
   7. A pending operation will be approved by the server only after all criteria of a single combination are entirely met

#### 3.2.1 Examples

This section is non-normative.

Example 2: Policy matching either a FPS-, or Face Recognition-based Authenticator

    {
      "accepted":
      [
    	[{ "userVerification": 2, "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]}],
        	[{ "userVerification": 16, "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]}]
      ]
    }

Example 3: Policy matching authenticators implementing FPS and Face Recognition as alternative combination of user verification methods.

    {
      "accepted":
      [
    	[{ "userVerification": 18, "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]}]
      ]
    }

Combining these two bit-flags and the flag `USER_VERIFY_ALL` (USER_VERIFY_ALL = 1024) into a single `userVerification` value would match authenticators implementing FPS and Face Recognition as a mandatory combination of user verification methods.

Example 4: Policy matching authenticators implementing FPS and Face Recognition as mandatory combination of user verification methods.

    {
      "accepted": [ [{ "userVerification": 1042, "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]}] ]
    }

The next example requires two authenticators to be used:

Example 5: Policy matching the combination of a FPS based and a Face Recognition based authenticator

    {
      "accepted":
      [
    	[
    	  { "userVerification": 2, "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]},
    	  { "userVerification": 16, "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]}
    	]
      ]
    }

Other criteria can be specified in addition to the `userVerification`:

Example 6: Policy requiring the combination of a bound FPS based and a bound Face Recognition based authenticator

    {
      "accepted":
      [
    	[
    	  { "userVerification": 2, "attachmentHint": 1, "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]},
    	  { "userVerification": 16, "attachmentHint": 1, "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]}
            ]
      ]
    }

The policy for accepting authenticators of vendor with ID `1234` only is as follows:

Example 7: Policy accepting all authenticators from vendor with ID 1234

    {
      "accepted":
      [ [{ "vendorID": "1234", "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]}] ]
    }

### 3.3 Version Negotiation

The UAF protocol includes multiple versioned constructs: UAF protocol version, the version of Key Registration Data and Signed Data objects (identified by their respective tags, see [UAFRegistry]), and the ASM version, see [UAFASM].

Note

The Key Registration Data and Signed Data objects have to be parsed and verified by the FIDO Server. This verification is only possible if the FIDO Server understands their encoding and the content. Each UAF protocol version supports a set of Key Registration Data and SignedData object versions (called Assertion Schemes). Similarly each of the ASM versions supports a set Assertion Scheme versions.

As a consequence the FIDO UAF Client MUST select the authenticators which will generate the appropriately versioned constructs.

For version negotiation the FIDO UAF Client MUST perform the following steps:

1. Create a set (`FC_Version_Set`) of version pairs, ASM version (`asmVersion`) and UAF Protocol version (`upv`) and add all pairs supported by the FIDO UAF Client into `FC_Version_Set`
   - e.g. `[{upv1, asmVersion1}, {upv2, asmVersion1}, ...]`
   Note

   The ASM versions are retrieved from the `AuthenticatorInfo.asmVersion` field. The UAF protocol version is derived from the related `AuthenticatorInfo.assertionScheme` field.

2. Intersect `FC_Version_Set` with the set of `upv` included in UAF Message (i.e. keep only those pairs where the `upv` value is also contained in the UAF Message).
3. Select authenticators which are allowed by the UAF Message Policy. For each authenticator:
   - Construct a set (`Authnr_Version_Set`) of version pairs including authenticator supported `asmVersion` and the compatible `upv(s)`.
     - e.g. `[{upv1, asmVersion1}, {upv2, asmVersion1}, ...]`
   - Intersect `Authnr_Version_Set` with `FC_Version_Set` and select highest version pair from it.
     - Take the pair where the `upv` is highest. In all these pairs leave only the one with highest `asmVersion`.
   - Use the remaining version pair with this authenticator

Note

Each version consists of `major` and `minor` fields. In order to compare two versions - compare the Major fields and if they are equal compare the Minor fields.

Each UAF message contains a version field `upv`. UAF Protocol version negotiation is always between FIDO UAF Client and FIDO Server.

A possible implementation optimization is to have the RP web application itself preemptively convey to the FIDO Server the UAF protocol version(s) (UPV) supported by the FIDO Client. This allows the FIDO Server to craft its UAF messages using the UAF version most preferred by both the FIDO client and server.

### 3.4 Registration Operation

Note

The Registration operation allows the FIDO Server and the FIDO Authenticator to agree on an authentication key.

Fig. 6 UAF Registration Sequence Diagram

The steps 11a and 11b and 12 to 13 are not always necessary as the related data could be cached.

The following diagram depicts the cryptographic data flow for the registration sequence.

Fig. 7 UAF Registration Cryptographic Data Flow

The FIDO Server sends the `AppID` (see section AppID and FacetID Assertion), the authenticator Policy, the `ServerChallenge` and the `Username` to the FIDO UAF Client.

The FIDO UAF Client computes the `FinalChallengeParams` (FCH) from the `ServerChallenge` and some other values and sends the `AppID`, the `FCH` and the `Username` to the authenticator.

The authenticator creates a Key Registration Data object (e.g. `TAG_UAFV1_KRD`, see [UAFAuthnrCommands]) containing the hash of `FCH`, the newly generated user public key (UAuth.pub) and some other values and signs it (see section Authenticator Attestation for more details). This KRD object is then cryptographically verified by the FIDO Server.

#### 3.4.1 Registration Request Message

UAF Registration request message is represented as an array of dictionaries. The array MUST contain exactly one dictionary. The request is defined as RegistrationRequest dictionary.

Example 8: UAF Registration Request

    [{
        "header": {
          "upv": {
            "major": 1,
            "minor": 1
          },
          "op": "Reg",
     "appID": "https://uaf-test-1.noknoktest.com:8443/SampleApp/uaf/facets",
          "serverData": "IjycjPZYiWMaQ1tKLrJROiXQHmYG0tSSYGjP5mgjsDaM17RQgq0
    dl3NNDDTx9d-aSR_6hGgclrU2F2Yj-12S67v5VmQHj4eWVseLulHdpk2v_hHtKSvv_DFqL4n
    2IiUY6XZWVbOnvg"
        },
        "challenge": "H9iW9yA9aAXF_lelQoi_DhUk514Ad8Tqv0zCnCqKDpo",
        "username": "apa",
        "policy": {
          "accepted": [
            [
              {
                "userVerification": 512,
                "keyProtection": 1,
                "tcDisplay": 1,
                "authenticationAlgorithms": [
                  1
                ],
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              }
            ],
            [
              {
                "userVerification": 4,
                "keyProtection": 1,
                "tcDisplay": 1,
                "authenticationAlgorithms": [
                  1
                ],
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              }
            ],
            [
              {
                "userVerification": 4,
                "keyProtection": 1,
                "tcDisplay": 1,
                "authenticationAlgorithms": [
                  2
                ]
              }
            ],
            [
              {
                "userVerification": 2,
                "keyProtection": 4,
                "tcDisplay": 1,
                "authenticationAlgorithms": [
                  2
                ]
              }
            ],
            [
              {
                "userVerification": 4,
                "keyProtection": 2,
                "tcDisplay": 1,
                "authenticationAlgorithms": [
                  1,
                  3
                ]
              }
            ],
            [
              {
                "userVerification": 2,
                "keyProtection": 2,
                "authenticationAlgorithms": [
                  2
                ]
              }
            ],
            [
              {
                "userVerification": 32,
                "keyProtection": 2,
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              },
              {
                "userVerification": 2,
                "authenticationAlgorithms": [
                  1,
                  3
                ],
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              },
              {
                "userVerification": 2,
                "authenticationAlgorithms": [
                  1,
                  3
                ],
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              },
              {
                "userVerification": 4,
                "keyProtection": 1,
                "authenticationAlgorithms": [
                  1,
                  3
                ],
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              }
            ]
          ],
          "disallowed": [
            {
              "userVerification": 512,
              "keyProtection": 16,
              "assertionSchemes": [
                "UAFV1TLV"
              ]
            },
            {
              "userVerification": 256,
              "keyProtection": 16
            },
            {
              "aaid": [
                "ABCD#ABCD"
              ],
              "keyIDs": [
                "RfY_RDhsf4z5PCOhnZExMeVloZZmK0hxaSi10tkY_c4"
              ]
            }
          ]
        }
    }]

#### 3.4.2 RegistrationRequest dictionary

RegistrationRequest contains a single, versioned, registration request.

    dictionary RegistrationRequest {
        required OperationHeader header;
        required ServerChallenge challenge;
        required DOMString       username;
        required Policy          policy;
    };

##### 3.4.2.1 Dictionary `RegistrationRequest` Members

`header` of type required OperationHeader
  Operation header. `Header.op` MUST be "Reg"
`challenge` of type required ServerChallenge
  Server-provided challenge value
`username` of type required DOMString
  `string[1..128]`

  A human-readable user name intended to allow the user to distinguish and select from among different accounts at the same relying party.

`policy` of type required Policy
  Describes which types of authenticators are acceptable for this registration operation

#### 3.4.3 AuthenticatorRegistrationAssertion dictionary

Contains the authenticator's response to a RegistrationRequest message:

    dictionary AuthenticatorRegistrationAssertion {
        required DOMString                    assertionScheme;
        required DOMString                    assertion;
        DisplayPNGCharacteristicsDescriptor[] tcDisplayPNGCharacteristics;
        Extension[]                           exts;
    };

##### 3.4.3.1 Dictionary `AuthenticatorRegistrationAssertion` Members

`assertionScheme` of type required DOMString
  The name of the Assertion Scheme used to encode the `assertion`. See UAF Supported Assertion Schemes for details.
  Note

  This assertionScheme is not part of a signed object and hence considered the suspected assertionScheme.

`assertion` of type required DOMString
  `base64url(byte[1..4096])` Contains the `TAG_UAFV1_REG_ASSERTION` object containing the assertion scheme specific KeyRegistrationData (KRD) object which in turn contains the newly generated `UAuth.pub` and is signed by the Attestation Private Key.

  This assertion MUST be generated by the authenticator and it MUST be used only in this Registration operation. The format of this assertion can vary from one assertion scheme to another (e.g. for "UAFV1TLV" assertion scheme it MUST be `TAG_UAFV1_KRD`).

`tcDisplayPNGCharacteristics` of type array of DisplayPNGCharacteristicsDescriptor
  Supported transaction PNG type [FIDOMetadataStatement]. For the definition of the DisplayPNGCharacteristicsDescriptor structure See [FIDOMetadataStatement].
`exts` of type array of `Extension`
  Contains Extensions prepared by the authenticator

#### 3.4.4 Registration Response Message

A UAF Registration response message is represented as an array of dictionaries. Each dictionary contains a registration response for a specific protocol version. The array MUST NOT contain two dictionaries of the same protocol version. The response is defined as RegistrationResponse dictionary.

Example 9: Registration Response

    [{
        "assertions": [
          {
            "assertion": "AT7uAgM-sQALLgkAQUJDRCNBQkNEDi4HAAABAQEAAAEKLiAA9t
    BzZC64ecgVQBGSQb5QtEIPC8-Vav4HsHLZDflLaugJLiAAZMCPn92yHv1Ip-iCiBb6i4ADq6
    ZOv569KFQCvYSJfNgNLggAAQAAAAEAAAAMLkEABJsvEtUsVKh7tmYHhJ2FBm3kHU-OCdWiUY
    VijgYa81MfkjQ1z6UiHbKP9_nRzIN9anprHqDGcR6q7O20q_yctZAHPjUCBi5AACv8L7YlRM
    x10gPnszGO6rLFqZFmmRkhtV0TIWuWqYxd1jO0wxam7i5qdEa19u4sfpHFZ9RGI_WHxINkH8
    FfvAwFLu0BMIIB6TCCAY8CAQEwCQYHKoZIzj0EATB7MQswCQYDVQQGEwJVUzELMAkGA1UECA
    wCQ0ExCzAJBgNVBAcMAlBBMRAwDgYDVQQKDAdOTkwsSW5jMQ0wCwYDVQQLDAREQU4xMRMwEQ
    YDVQQDDApOTkwsSW5jIENBMRwwGgYJKoZIhvcNAQkBFg1ubmxAZ21haWwuY29tMB4XDTE0MD
    gyODIxMzU0MFoXDTE3MDUyNDIxMzU0MFowgYYxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQT
    EWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzEQMA4GA1UECgwHTk5MLEluYzENMAsGA1UECwwERE
    FOMTETMBEGA1UEAwwKTk5MLEluYyBDQTEcMBoGCSqGSIb3DQEJARYNbm5sQGdtYWlsLmNvbT
    BZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABCGBt3CIjnDowzSiF68C2aErYXnDUsWXOYxqIP
    im0OWg9FFdUYCa6AgKjn1R99Ek2d803sGKROivnavmdVH-SnEwCQYHKoZIzj0EAQNJADBGAi
    EAzAQujXnSS9AIAh6lGz6ydypLVTsTnBzqGJ4ypIqy_qUCIQCFsuOEGcRV-o4GHPBph_VMrG
    3NpYh2GKPjsAim_cSNmQ",
            "assertionScheme": "UAFV1TLV"
          }
        ],
        "fcParams": "eyJhcHBJRCI6Imh0dHBzOi8vdWFmLXRlc3QtMS5ub2tub2t0ZXN0LmN
    vbTo4NDQzL1NhbXBsZUFwcC91YWYvZmFjZXRzIiwiY2hhbGxlbmdlIjoiSDlpVzl5QTlhQVh
    GX2xlbFFvaV9EaFVrNTE0QWQ4VHF2MHpDbkNxS0RwbyIsImNoYW5uZWxCaW5kaW5nIjp7fSw
    iZmFjZXRJRCI6ImNvbS5ub2tub2suYW5kcm9pZC5zYW1wbGVhcHAifQ",
        "header": {
     "appID": "https://uaf-test-1.noknoktest.com:8443/SampleApp/uaf/facets",
          "op": "Reg",
          "serverData": "IjycjPZYiWMaQ1tKLrJROiXQHmYG0tSSYGjP5mgjsDaM17RQgq0
    dl3NNDDTx9d-aSR_6hGgclrU2F2Yj-12S67v5VmQHj4eWVseLulHdpk2v_hHtKSvv_DFqL4n
    2IiUY6XZWVbOnvg",
          "upv": {
            "major": 1,
            "minor": 1
          }
        }
    }]

Note

Line breaks in fcParams have been inserted for improving readability.

#### 3.4.5 RegistrationResponse dictionary

Contains all fields related to the registration response.

    dictionary RegistrationResponse {
        required OperationHeader                      header;
        required DOMString                            fcParams;
        required AuthenticatorRegistrationAssertion[] assertions;
    };

##### 3.4.5.1 Dictionary `RegistrationResponse` Members

`header` of type required OperationHeader
  `Header.op` MUST be "Reg".
`fcParams` of type required DOMString
  The base64url-encoded serialized [RFC4627] `FinalChallengeParams` using UTF8 encoding (see FinalChallengeParams dictionary) which contains all parameters required for the server to verify the Final Challenge.
`assertions` of type array of required AuthenticatorRegistrationAssertion
  Response data for each Authenticator being registered.

#### 3.4.6 Registration Processing Rules

##### 3.4.6.1 Registration Request Generation Rules for FIDO Server

The policy contains a two-dimensional array of allowed `MatchCriteria` (see Policy). This array can be considered a list (first dimension) of sets (second dimension) of authenticators (identified by `MatchCriteria`). All authenticators in a specific set MUST be registered simultaneously in order to match the policy. But any of those sets in the list are valid, as the list elements are alternatives.

The FIDO Server MUST follow the following steps:

1. Construct appropriate authentication policy `p`
   1. for each set of alternative authenticators do
      1. Create an array of MatchCriteria objects, containing the set of authenticators to be registered simultaneously that need to be identified by separate MatchCriteria objects `m`.
         1. For each collection of authenticators `a` to be registered simultaneously that can be identified by the same rule, create a MatchCriteria object `m`, where
            - `m.aaid` MAY be combined with (one or more of) `m.keyIDs`, `m.attachmentHint`, `m.authenticatorVersion`, and `m.exts`, but `m.aaid` MUST NOT be combined with any other match criteria field.
            - If `m.aaid` is not provided - at least `m.authenticationAlgorithms` and `m.assertionSchemes` MUST be provided
         2. Add `m` to `v`, e.g. `v[j+1]=m`.
      2. Add `v` to `p.allowed`, e.g. `p.allowed[i+1]=v`
   2. Create MatchCriteria objects `m[]` for all disallowed Authenticators.
      1. For each already registered AAID for the current user
         1. Create a MatchCriteria object `m` and add AAID and corresponding KeyIDs to `m.aaid` and `m.KeyIDs`.

         The FIDO Server MUST include already registered AAIDs and KeyIDs into field `p.disallowed` to hint that the client should not register these again.

      2. Create a MatchCriteria object `m` and add the AAIDs of all disallowed Authenticators to `m.aaid`.

         The status (as provided in the metadata TOC (Table-of-Contents file) [FIDOMetadataService]) of some authenticators might be unacceptable. Such authenticators SHOULD be included in `p.disallowed`.

      3. If needed - create MatchCriteria `m` for other disallowed criteria (e.g. unsupported authenticationAlgs)
      4. Add all `m` to `p.disallowed`.
2. Create a `RegistrationRequest` object `r` with appropriate `r.header` for each supported version, and
   1. FIDO Servers SHOULD NOT assume any implicit integrity protection of `r.header.serverData`.

      FIDO Servers that depend on the integrity of `r.header.serverData` SHOULD apply and verify a cryptographically secure Message Authentication Code (MAC) to serverData and they SHOULD also cryptographically bind serverData to the related message, e.g. by re-including `r.challenge`, see also section ServerData and KeyHandle.

      Note

      All other FIDO components (except the FIDO server) will treat `r.header.serverData` as an opaque value. As a consequence the FIDO server can implement any suitable cryptographic protection method.

   2. Generate a random challenge and assign it to `r.challenge`
   3. Assign the username of the user to be registered to `r.username`
   4. Assign `p` to `r.policy`.
   5. Append `r` to the array `o` of message with various versions (`RegistrationRequest`)
3. Send `o` to the FIDO UAF Client

##### 3.4.6.2 Registration Request Processing Rules for FIDO UAF Clients

The FIDO UAF Client MUST perform the following steps:

1. Choose the message `m` with upv set to the appropriate version number.
2. Parse the message `m`
3. If a mandatory field in UAF message is not present or a field doesn't correspond to its type and value - reject the operation
4. Filter the available authenticators with the given policy and present the filtered authenticators to User. Make sure to not include already registered authenticators for this user specified in `RegRequest.policy.disallowed[].keyIDs`
5. Obtain `FacetID` of the requesting Application. If the `AppID` is missing or empty, set the `AppID` to the `FacetID`.

   Verify that the `FacetID` is authorized for the `AppID` according to the algorithms in [FIDOAppIDAndFacets].

   - If the `FacetID` of the requesting Application is not authorized, reject the operation
6. Obtain TLS data if it is available
7. Create a `FinalChallengeParams` structure `fcp` and set `fcp.appID`, `fcp.challenge`, `fcp.facetID`, and `fcp.channelBinding` appropriately. Serialize [RFC4627] fcp using UTF8 encoding and base64url encode it.
   - `FinalChallenge = base64url(serialize(utf8encode(fcp)))`
8. For each authenticator that matches UAF protocol version (see section Version Negotiation) and user agrees to register:
   1. Add `AppID`, `Username`, `FinalChallenge`, `AttestationType` and all other required fields to the ASMRequest [UAFASM].

   The FIDO UAF Client MUST follow the server policy and find the single preferred attestation type. A single attestation type MUST be provided to the ASM.

   2. Send the ASMRequest to the ASM. If the ASM returns an error, handle that error appropriately. The status code returned by the ASM [UAFASM] must be mapped to a status code defined in [UAFAppAPIAndTransport] as specified in section 3.4.6.2.1 Mapping ASM Status Codes to ErrorCode.

###### 3.4.6.2.1 Mapping ASM Status Codes to ErrorCode

ASMs are returning a status code in their responses to the FIDO Client. The FIDO Client needs to act on those responses and also map the status code returned the ASM [UAFASM] to an ErrorCode specified in [UAFAppAPIAndTransport].

The mapping of ASM status codes to ErrorCode is specified here:

ASM Status Code | ErrorCode | Comment
--- | --- | ---
`UAF_ASM_STATUS_OK` | `NO_ERROR` | Pass-through success status.
`UAF_ASM_STATUS_ERROR` | `UNKNOWN` | Map to `UNKNOWN`.
`UAF_ASM_STATUS_ACCESS_DENIED` | `AUTHENTICATOR_ACCESS_DENIED` | Map to `AUTHENTICATOR_ACCESS_DENIED`
`UAF_ASM_STATUS_USER_CANCELLED` | `USER_CANCELLED` | Pass-through status code.
`UAF_ASM_STATUS_CANNOT_RENDER_TRANSACTION_CONTENT` | `INVALID_TRANSACTION_CONTENT` | Map to `INVALID_TRANSACTION_CONTENT`. This code indicates a problem to be resolved by the entity providing the transaction text.
`UAF_ASM_STATUS_KEY_DISAPPEARED_PERMANENTLY` | `KEY_DISAPPEARED_PERMANENTLY` | Pass-through status code. It indicates that the Uauth key disappeared permanently and the RP App might want to trigger re-registration of the authenticator.
`UAF_ASM_STATUS_AUTHENTICATOR_DISCONNECTED` | `NO_SUITABLE_AUTHENTICATOR` or `WAIT_USER_ACTION` | Retry operation with other suitable authenticators and map to `NO_SUITABLE_AUTHENTICATOR` if the problem persists. Return `WAIT_USER_ACTION` if being called while retrying.
`UAF_ASM_STATUS_USER_NOT_RESPONSIVE` | `USER_NOT_RESPONSIVE` | Pass-through status code. The RP App might want to retry the operation once the user pays attention to the application again.
`UAF_ASM_STATUS_INSUFFICIENT_AUTHENTICATOR_RESOURCES` | `INSUFFICIENT_AUTHENTICATOR_RESOURCES` | The FIDO Client SHALL try other authenticators matching the policy. If none exist, pass-through status code.
`UAF_ASM_STATUS_USER_LOCKOUT` | `USER_LOCKOUT` | Pass-through status code.
`UAF_ASM_STATUS_USER_NOT_ENROLLED` | `USER_NOT_ENROLLED` | Pass-through status code.
Any other status code | `UNKNOWN` | Map any unknown error code to `UNKNOWN`. This might happen when a FIDO Client communicates with an ASM implementing a newer UAF specification than the FIDO Client.

##### 3.4.6.3 Registration Request Processing Rules for FIDO Authenticator

See [UAFAuthnrCommands], section "Register Command".

##### 3.4.6.4 Registration Response Generation Rules for FIDO UAF Client

The FIDO UAF Client MUST follow the steps:

1. Create a `RegistrationResponse` message
2. Copy `RegistrationRequest.header` into `RegistrationResponse.header`
   Note

   When the `appID` provided in the request was empty, the FIDO Client must set the `appID` in this header to the facetID (see [FIDOAppIDAndFacets]).

3. Set `RegistrationResponse.fcParams` to `FinalChallenge` (base64url encoded serialized and utf8 encoded FinalChallengeParams)
4. Append the response from each Authenticator into `RegistrationResponse.assertions`
5. Send `RegistrationResponse` message to FIDO Server

##### 3.4.6.5 Registration Response Processing Rules for FIDO Server

Note

The following processing rules assume that Authenticator supports "UAFV1TLV" assertion scheme. Currently "UAFV1TLV" is the only defined and supported assertion scheme. When a new assertion scheme is added to UAF protocol - this section will be extended with corresponding processing rules.

The FIDO Server MUST follow the steps:

1. Parse the message
   1. If protocol version (`RegistrationResponse.header.upv`) is not supported – reject the operation
   2. If a mandatory field in UAF message is not present or a field doesn't correspond to its type and value - reject the operation
2. Verify that `RegistrationResponse.header.serverData`, if used, passes any implementation-specific checks against its validity. See also section ServerData and KeyHandle.
3. base64url decode `RegistrationResponse.fcParams` and convert it into an object (`fcp`)
4. Verify each field in fcp and make sure it is valid:
   1. Make sure `fcp.appID` corresponds to the one stored by the FIDO Server
      Note

      When the `appID` provided in the request was empty, the FIDO Client must set the `appID` to the facetID (see [FIDOAppIDAndFacets]). In this case, the Uauth key cannot be used by other application facets.

   2. Make sure `fcp.facetID` is in the list of trusted FacetIDs [FIDOAppIDAndFacets]
   3. Make sure `fcp.channelBinding` is as expected (see section ChannelBinding dictionary)
      Note

      There might be legitimate situations in which some methods of channel binding fail (see section 4.3.4 TLS Binding).

   4. Reject the response if any of these checks fails
   5. Make sure `fcp.challenge` has really been generated by the FIDO Server for this operation and it is not expired
5. For each assertion `a` in `RegistrationResponse.assertions`
   1. Parse TLV data from `a.assertion` assuming it is encoded according to the suspected assertion scheme `a.assertionScheme` and make sure it contains all mandatory fields (indicated in Authenticator Metadata) it is supposed to have and has a valid syntax.
      - If it doesn't - continue with next assertion
   2. Retrieve the AAID from the assertion.
      Note

      The AAID in `TAG_UAFV1_KRD` is contained in `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.TAG_AAID`.

   3. Verify that `a.assertionScheme` matches `Metadata(AAID).assertionScheme`
      - If it doesn't match - continue with next assertion
   4. Verify that the AAID indeed matches the policy specified in the registration request.
      Note

      Depending on the policy (e.g. in the case of AND combinations), it might be required to evaluate other assertions included in this `RegistrationResponse` in order to determine whether this AAID matches the policy.

      - If it doesn't match the policy - continue with next assertion
   5. Locate authenticator-specific authentication algorithms from the authenticator metadata [FIDOMetadataStatement] using the AAID.
   6. Hash `RegistrationResponse.fcParams` using hashing algorithm suitable for this authenticator type. Look up the hash algorithm in authenticator metadata, field `AuthenticationAlgs`. It is the hash algorithm associated with the first entry related to a constant with prefix ALG_SIGN.
      - `FCHash = hash(RegistrationResponse.fcParams)`
   7. if `a.assertion` contains an object of type `TAG_UAFV1_REG_ASSERTION`, then
      1. if `a.assertion.TAG_UAFV1_REG_ASSERTION` contains `TAG_UAFV1_KRD` as first element:
         1. Obtain `Metadata(AAID).AttestationType` for the AAID and make sure that `a.assertion.TAG_UAFV1_REG_ASSERTION` contains the most preferred attestation tag specified in field `MatchCriteria.attestationTypes` in `RegistrationRequest.policy` (if this field is present).
            - If `a.assertion.TAG_UAFV1_REG_ASSERTION` doesn't contain the preferred attestation - it is RECOMMENDED to skip this assertion and continue with next one
         2. Make sure that `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.FinalChallengeHash` == `FCHash`
            - If comparison fails - continue with next assertion
         3. Obtain `Metadata(AAID).AuthenticatorVersion` for the AAID and make sure that it is lower or equal to `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.AuthenticatorVersion`.
            - If `Metadata(AAID).AuthenticatorVersion` is higher (i.e. the authenticator firmware is outdated), it is RECOMMENDED to assume increased risk. See sections "StatusReport dictionary" and "Metadata TOC object Processing Rules" in [FIDOMetadataService] for more details on this.
         4. Check whether `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.RegCounter` is acceptable, i.e. it is either not supported (value is 0 or the field isKeyRestricted is set to 'false' in the related Metadata Statement) or it is not exceedingly high
            - If `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.RegCounter` is exceedingly high, this assertion might be skipped and processing will continue with next one
         5. If `a.assertion.TAG_UAFV1_REG_ASSERTION` contains `TAG_ATTESTATION_BASIC_FULL` tag
            1. If entry `AttestationRootCertificates` for the AAID in the metadata [FIDOMetadataStatement] contains at least one element:
               1. Obtain contents of all `TAG_ATTESTATION_CERT` tags from `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_ATTESTATION_BASIC_FULL` object. The occurrences are ordered (see [UAFAuthnrCommands]) and represent the attestation certificate followed by the related certificate chain.
               2. Obtain all entries of `AttestationRootCertificates` for the AAID in authenticator Metadata, field `AttestationRootCertificates`.
               3. Verify the attestation certificate and the entire certificate chain up to the Attestation Root Certificate using Certificate Path Validation as specified in [RFC5280]
               - If verification fails – continue with next assertion
               4. Verify `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.TAG_ATTESTATION_BASIC_FULL.Signature` using the attestation certificate (obtained before).
               - If verification fails – continue with next assertion
            2. If `Metadata(AAID).AttestationRootCertificates` for this AAID is empty - continue with next assertion
            3. Mark assertion as positively verified
         6. If `a.assertion.TAG_UAFV1_REG_ASSERTION` contains an object of type `TAG_ATTESTATION_BASIC_SURROGATE`
            1. There is no real attestation for the AAID, so we just assume the AAID is the real one.
            2. If entry `AttestationRootCertificates` for the AAID in the metadata is empty
               - Verify `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_ATTESTATION_BASIC_SURROGATE.Signature` using `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.TAG_PUB_KEY`
                 - If verification fails – continue with next assertion
            3. If entry `AttestationRootCertificates` for the AAID in the metadata is not empty - continue with next assertion (as the AAID obviously is expecting a different attestation method).
            4. Mark assertion as positively verified
         7. If `a.assertion.TAG_UAFV1_REG_ASSERTION` contains an object of type `TAG_ATTESTATION_ECDAA`
            1. If entry `ecdaaTrustAnchors` for the AAID in the metadata [FIDOMetadataStatement] contains at least one element:
               1. For each of the `ecdaaTrustAnchors` entries, perform the ECDAA Verify operation as specified in [FIDOEcdaaAlgorithm].
                  - If verification fails – continue with next `ecdaaTrustAnchors` entry
               2. If no ECDAA Verify operation succeeded – continue with next assertion
            2. If `Metadata(AAID).ecdaaTrustAnchors` for this AAID is empty - continue with next assertion
            3. Mark assertion as positively verified and the authenticator indeed is of model as indicated by the AAID.
         8. If `a.assertion.TAG_UAFV1_REG_ASSERTION` contains another `TAG_ATTESTATION` tag - verify the attestation by following appropriate processing rules applicable to that attestation. Currently this document defines the processing rules for Basic Attestation and direct anonymous attestation (ECDAA).
      2. if `a.assertion.TAG_UAFV1_REG_ASSERTION` contains a different object than `TAG_UAFV1_KRD` as first element, then follow the rules specific to that object.
      3. Extract `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.PublicKey` into PublicKey, `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.KeyID` into KeyID, `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.SignCounter` into SignCounter, `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.TAG_ASSERTION_INFO.authenticatorVersion` into AuthenticatorVersion, `a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.TAG_AAID` into AAID.
   8. if `a.assertion` doesn't contain an object of type `TAG_UAFV1_REG_ASSERTION`, then skip this assertion (as in this UAF v1 only `TAG_UAFV1_REG_ASSERTION` is defined).
6. For each positively verified assertion `a`
   - Store PublicKey, KeyID, SignCounter, AuthenticatorVersion, AAID and `a.tcDisplayPNGCharacteristics` into a record associated with the user's identity. If an entry with the same pair of AAID and KeyID already exists then fail (should never occur).

### 3.5 Authentication Operation

Note
Fig. 8 UAF Authentication Sequence Diagram

The steps 7a and 7a and 8 to 9 are not always necessary as the related data could be cached.

The TransactionText (TranTxt) is only required in the case of Transaction Confirmation (see section 3.5.1 Transaction dictionary), it is absent in the case of a pure Authenticate operation.

During this operation, the FIDO Server asks the FIDO UAF Client to authenticate user with server-specified authenticators, and return an authentication response.

In order for this operation to succeed, the authenticator and the relying party must have a previously shared registration.

Fig. 9 UAF Authentication Cryptographic Data Flow

Diagram of cryptographic flow:

The FIDO Server sends the `AppID` (see [FIDOAppIDAndFacets]), the authenticator policy and the `ServerChallenge` to the FIDO UAF Client.

The FIDO UAF Client computes the hash of the `FinalChallengeParams`, produced from the `ServerChallenge` and other values, as described in this document, and sends the `AppID` and hashed `FinalChallengeParams` to the Authenticator.

The authenticator creates the `SignedData` object (see `TAG_UAFV1_SIGNED_DATA` in [UAFAuthnrCommands]) containing the hash of the final challenge parameters, and some other values and signs it using the `UAuth.priv` key. This assertion is then cryptographically verified by the FIDO Server.

#### 3.5.1 Transaction dictionary

Contains the Transaction Content provided by the FIDO Server:

    dictionary Transaction {
        required DOMString                  contentType;
        required DOMString                  content;
        DisplayPNGCharacteristicsDescriptor tcDisplayPNGCharacteristics;
    };

##### 3.5.1.1 Dictionary `Transaction` Members

`contentType` of type required DOMString
  Contains the MIME Content-Type supported by the authenticator according its metadata statement (see [FIDOMetadataStatement]).

  This version of the specification only supports the values `text/plain` or `image/png`.

`content` of type required DOMString
  `base64url(byte[1...])`

  Contains the base64-url encoded transaction content according to the `contentType` to be shown to the user.

  If `contentType` is "text/plain" then the content MUST be the base64-url encoding of the ASCII encoded text with a maximum of 200 characters.

`tcDisplayPNGCharacteristics` of type DisplayPNGCharacteristicsDescriptor
  Transaction content PNG characteristics. For the definition of the DisplayPNGCharacteristicsDescriptor structure See [FIDOMetadataStatement]. This field MUST be present if the contentType is "image/png".

#### 3.5.2 Authentication Request Message

UAF Authentication request message is represented as an array of dictionaries. The array MUST contain exactly one dictionary. The request is defined as AuthenticationRequest dictionary.

Example 10: UAF Authentication Request

    [{
        "header": {
          "upv": {
            "major": 1,
            "minor": 1
          },
          "op": "Auth",
     "appID": "https://uaf-test-1.noknoktest.com:8443/SampleApp/uaf/facets",
          "serverData": "5s7n8-7_LDAtRIKKYqbAtTTOezVKCjl2mPorYzbpxRrZ-_3wWro
    MXsF_pLYjNVm_l7bplAx4bkEwK6ibil9EHGfdfKOQ1q0tyEkNJFOgqdjVmLioroxgThlj8Is
    tpt7q"
        },
        "challenge": "HQ1VkTUQC1NJDOo6OOWdxewrb9i5WthjfKIehFxpeuU",
        "policy": {
          "accepted": [
            [
              {
                "userVerification": 512,
                "keyProtection": 1,
                "tcDisplay": 1,
                "authenticationAlgorithms": [
                  1
                ],
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              }
            ],
            [
              {
                "userVerification": 4,
                "keyProtection": 1,
                "tcDisplay": 1,
                "authenticationAlgorithms": [
                  1
                ],
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              }
            ],
            [
              {
                "userVerification": 4,
                "keyProtection": 1,
                "tcDisplay": 1,
                "authenticationAlgorithms": [
                  2
                ]
              }
            ],
            [
              {
                "userVerification": 2,
                "keyProtection": 4,
                "tcDisplay": 1,
                "authenticationAlgorithms": [
                  2
                ]
              }
            ],
            [
              {
                "userVerification": 4,
                "keyProtection": 2,
                "tcDisplay": 1,
                "authenticationAlgorithms": [
                  1,
                  3
                ]
              }
            ],
            [
              {
                "userVerification": 2,
                "keyProtection": 2,
                "authenticationAlgorithms": [
                  2
                ]
              }
            ],
            [
              {
                "userVerification": 32,
                "keyProtection": 2,
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              },
              {
                "userVerification": 2,
                "authenticationAlgorithms": [
                  1,
                  3
                ],
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              },
              {
                "userVerification": 2,
                "authenticationAlgorithms": [
                  1,
                  3
                ],
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              },
              {
                "userVerification": 4,
                "keyProtection": 1,
                "authenticationAlgorithms": [
                  1,
                  3
                ],
                "assertionSchemes": [
                  "UAFV1TLV"
                ]
              }
            ]
          ],
          "disallowed": [
            {
              "userVerification": 512,
              "keyProtection": 16,
              "assertionSchemes": [
                "UAFV1TLV"
              ]
            },
            {
              "userVerification": 256,
              "keyProtection": 16
            }
          ]
        }
    }]

#### 3.5.3 AuthenticationRequest dictionary

Contains the UAF Authentication Request Message:

    dictionary AuthenticationRequest {
        required OperationHeader header;
        required ServerChallenge challenge;
        Transaction[]            transaction;
        required Policy          policy;
    };

##### 3.5.3.1 Dictionary `AuthenticationRequest` Members

`header` of type required OperationHeader
  `Header.op` MUST be "Auth"
`challenge` of type required ServerChallenge
  Server-provided challenge value
`transaction` of type array of `Transaction`
  Transaction data to be explicitly confirmed by the user.

  The list contains the same transaction content in various content types and various image sizes. Refer to [FIDOMetadataStatement] for more information about Transaction Confirmation Display characteristics.

`policy` of type required Policy
  Server-provided policy defining what types of authenticators are acceptable for this authentication operation.

#### 3.5.4 AuthenticatorSignAssertion dictionary

Represents a response generated by a specific Authenticator:

    dictionary AuthenticatorSignAssertion {
        required DOMString assertionScheme;
        required DOMString assertion;
        Extension[]        exts;
    };

##### 3.5.4.1 Dictionary `AuthenticatorSignAssertion` Members

`assertionScheme` of type required DOMString
  The name of the Assertion Scheme used to encode `assertion`. See UAF Supported Assertion Schemes for details.
  Note

  This assertionScheme is not part of a signed object and hence considered the suspected assertionScheme.

`assertion` of type required DOMString
  `base64url(byte[1..4096])` Contains the assertion containing a signature generated by `UAuth.priv`, i.e. `TAG_UAFV1_AUTH_ASSERTION`.
`exts` of type array of `Extension`
  Any extensions prepared by the Authenticator

#### 3.5.5 AuthenticationResponse dictionary

Represents the response to a challenge, including the set of signed assertions from registered authenticators.

    dictionary AuthenticationResponse {
        required OperationHeader              header;
        required DOMString                    fcParams;
        required AuthenticatorSignAssertion[] assertions;
    };

##### 3.5.5.1 Dictionary `AuthenticationResponse` Members

`header` of type required OperationHeader
  `Header.op` MUST be "Auth"
`fcParams` of type required DOMString
  The field fcParams is the base64url-encoded serialized [RFC4627] FinalChallengeParams in UTF8 encoding (see FinalChallengeParams dictionary) which contains all parameters required for the server to verify the Final Challenge.
`assertions` of type array of required AuthenticatorSignAssertion
  The list of authenticator responses related to this operation.

#### 3.5.6 Authentication Response Message

UAF Authentication response message is represented as an array of dictionaries. The array MUST contain exactly one dictionary. The response is defined as AuthenticationResponse dictionary.

Example 11: UAF Authentication Response

    [{
        "assertions": [
          {
            "assertion": "Aj7WAAQ-jgALLgkAQUJDRCNBQkNEDi4FAAABAQEADy4gAHwyJA
    EX8t1b2wOxbaKOC5ZL7ACqbLo_TtiQfK3DzDsHCi4gAFwCUz-dOuafXKXJLbkUrIzjAU6oDb
    P8B9iLQRmCf58fEC4AAAkuIABkwI-f3bIe_Uin6IKIFvqLgAOrpk6_nr0oVAK9hIl82A0uBA
    ACAAAABi5AADwDOcBvPslX2bRNy4SvFhAwhEAoBSGUitgMUNChgUSMxss3K3ukekq1paG7Fv
    1v5mBmDCZVPt2NCTnjUxrjTp4",
            "assertionScheme": "UAFV1TLV"
          }
        ],
        "fcParams": "eyJhcHBJRCI6Imh0dHBzOi8vdWFmLXRlc3QtMS5ub2tub2t0ZXN0LmN
    vbTo4NDQzL1NhbXBsZUFwcC91YWYvZmFjZXRzIiwiY2hhbGxlbmdlIjoiSFExVmtUVVFDMU5
    KRE9vNk9PV2R4ZXdyYjlpNVd0aGpmS0llaEZ4cGV1VSIsImNoYW5uZWxCaW5kaW5nIjp7fSw
    iZmFjZXRJRCI6ImNvbS5ub2tub2suYW5kcm9pZC5zYW1wbGVhcHAifQ",
        "header": {
     "appID": "https://uaf-test-1.noknoktest.com:8443/SampleApp/uaf/facets",
          "op": "Auth",
          "serverData": "5s7n8-7_LDAtRIKKYqbAtTTOezVKCjl2mPorYzbpxRrZ-_3wWro
    MXsF_pLYjNVm_l7bplAx4bkEwK6ibil9EHGfdfKOQ1q0tyEkNJFOgqdjVmLioroxgThlj8Is
    tpt7q",
          "upv": {
            "major": 1,
            "minor": 1
          }
        }
    }]

Note

Line breaks in fcParams have been inserted for improving readability.

#### 3.5.7 Authentication Processing Rules

##### 3.5.7.1 Authentication Request Generation Rules for FIDO Server

The policy contains a 2-dimensional array of allowed MatchCriteria (see Policy). This array can be considered a list (first dimension) of sets (second dimension) of authenticators (identified by MatchCriteria). All authenticators in a specific set MUST be used for authentication simultaneously in order to match the policy. But any of those sets in the list are valid, i.e. the list elements are alternatives.

The FIDO Server MUST follow the steps:

1. Construct appropriate authentication policy `p`
   1. for each set of alternative authenticators do
      1. Create an 1-dimensional array of MatchCriteria objects v containing the set of authenticators to be used for authentication simultaneously that need to be identified by separate MatchCriteria objects `m`.
         1. For each collection of authenticators `a` to be used for authentication simultaneously that can be identified by the same rule, create a MatchCriteria object `m`, where
            - `m.aaid` MAY be combined with (one or more of) `m.keyIDs`, `m.attachmentHint`, `m.authenticatorVersion`, and `m.exts`, but `m.aaid` MUST NOT be combined with any other match criteria field.
            - If `m.aaid` is not provided - at least `m.authenticationAlgorithms` and `m.assertionSchemes` MUST be provided
            - In case of step-up authentication (i.e. in the case where it is expected the user is already known due to a previous authentication step) every item in `Policy.accepted` MUST include the `AAID` and `KeyID` of the authenticator registered for this account in order to avoid ambiguities when having multiple accounts at this relying party.
         2. Add `m` to `v`, e.g. `v[j+1]=m`.
      2. Add `v` to `p.allowed`, e.g. `p.allowed[i+1]=v`
   2. Create MatchCriteria objects `m[]` for all disallowed authenticators.
      1. Create a MatchCriteria object `m` and add AAIDs of all disallowed authenticators to `m.aaid`.

         The status (as provided in the metadata TOC [FIDOMetadataService]) of some authenticators might be unacceptable. Such authenticators SHOULD be included in `p.disallowed`.

      2. If needed - create MatchCriteria `m` for other disallowed criteria (e.g. unsupported authenticationAlgs)
      3. Add all `m` to `p.disallowed`.
2. Create an AuthenticationRequest object `r` with appropriate `r.header` for the supported version, and
   1. FIDO Servers SHOULD NOT assume any implicit integrity protection of `r.header.serverData`. FIDO Servers that depend on the integrity of `r.header.serverData` SHOULD apply and verify a cryptographically secure Message Authentication Code (MAC) to serverData and they SHOULD also cryptographically bind serverData to the related message, e.g. by re-including `r.challenge`, see also section ServerData and KeyHandle.
      Note

      All other FIDO components (except the FIDO server) will treat `r.header.serverData` as an opaque value. As a consequence the FIDO server can implement any suitable cryptographic protection method.

   2. Generate a random challenge and assign it to `r.challenge`
   3. If this is a transaction confirmation operation - look up TransactionConfirmationDisplayContentTypes/ TransactionConfirmationDisplayPNGCharacteristics from authenticator metadata of every participating AAID, generate a list of corresponding transaction content and insert the list into `r.transaction`.
      - If the authenticator reported (a dynamic) `AuthenticatorRegistrationAssertion.tcDisplayPNGCharacteristics` during Registration - it MUST be preferred over the (static) value specified in the authenticator Metadata.
   4. Set `r.policy` to our new policy object `p` created above, e.g. `r.policy = p`.
   5. Add the authentication request message the array
3. Send the array of authentication request messages to the FIDO UAF Client

##### 3.5.7.2 Authentication Request Processing Rules for FIDO UAF Client

The FIDO UAF Client MUST follow the steps:

1. Choose the message `m` with upv set to the appropriate version number.
2. Parse the message `m`
   - If a mandatory field in the UAF message is not present or a field doesn't correspond to its type and value then reject the operation
3. Obtain `FacetID` of the requesting Application. If the `AppID` is missing or empty, set the `AppID` to the `FacetID`.

   Verify that the `FacetID` is authorized for the `AppID` according to the algorithms in [FIDOAppIDAndFacets].

   - If the `FacetID` of the requesting Application is not authorized, reject the operation
4. Filter available authenticators with the given policy and present the filtered list to User.
5. Let the user select the preferred Authenticator.
6. Obtain TLS data if its available
7. Create a FinalChallengeParams structure `fcp` and set `fcp.AppID`, `fcp.challenge`, `fcp.facetID`, and `fcp.channelBinding` appropriately. Serialize [RFC4627] `fcp` using UTF8 encoding and base64url encode it.
   - `FinalChallenge = base64url(serialize(utf8encode(fcp)))`
8. For each authenticator that supports an Authenticator Interface Version AIV compatible with message version `AuthenticationRequest.header.upv` (see Version Negotiation) and user agrees to authenticate with:
   1. Add `AppID`, `FinalChallenge`, `Transactions` (if present), and all other fields to the ASMRequest.
   2. Send the ASMRequest to the ASM. If the ASM returns an error, handle that error appropriately. The status code returned by the ASM [UAFASM] must be mapped to a status code defined in [UAFAppAPIAndTransport] as specified in section 3.4.6.2.1 Mapping ASM Status Codes to ErrorCode.

##### 3.5.7.3 Authentication Request Processing Rules for FIDO Authenticator

See [UAFAuthnrCommands], section "Sign Command".

##### 3.5.7.4 Authentication Response Generation Rules for FIDO UAF Client

The FIDO UAF Client MUST follow the steps:

1. Create an AuthenticationResponse message
2. Copy `AuthenticationRequest.header` into `AuthenticationResponse.header`
   Note

   When the `appID` provided in the request was empty, the FIDO Client must set the `appID` in this header to the facetID (see [FIDOAppIDAndFacets]).

3. Fill out `AuthenticationResponse.FinalChallengeParams` with appropriate fields and then stringify it
4. Append the response from each authenticator into `AuthenticationResponse.assertions`
5. Send AuthenticationResponse message to the FIDO Server

##### 3.5.7.5 Authentication Response Processing Rules for FIDO Server

Note

The following processing rules assume that authenticator supports "UAFV1TLV" assertion scheme. Currently "UAFV1TLV" is the only defined and supported assertion scheme. When a new assertion scheme is added to UAF protocol - this section will be extended with corresponding processing rules.

The FIDO Server MUST follow the steps:

1. Parse the message
   1. If protocol version (`AuthenticationResponse.header.upv`) is not supported – reject the operation
   2. If a mandatory field in UAF message is not present or a field doesn't correspond to its type and value - reject the operation
2. Verify that `AuthenticationResponse.header.serverData`, if used, passes any implementation-specific checks against its validity. See also section ServerData and KeyHandle.
3. base64url decode `AuthenticationResponse.fcParams` and convert into an object (`fcp`)
4. Verify each field in fcp and make sure it's valid:
   1. Make sure `fcp.appID` corresponds to the one stored by the FIDO Server
      Note

      When the `appID` provided in the request was empty, the FIDO Client must set the `appID` to the facetID (see [FIDOAppIDAndFacets]). In this case, the Uauth key cannot be used by other application facets.

   2. Make sure `fcp.facetID` is in the list of trusted FacetIDs [FIDOAppIDAndFacets]
   3. Make sure `ChannelBinding` is as expected (see section ChannelBinding dictionary)
      Note

      There might be legitimate situations in which some methods of channel binding fail (see section 4.3.4 TLS Binding).

   4. Make sure `fcp.challenge` has really been generated by the FIDO Server for this operation and it is not expired
   5. Reject the response if any of the above checks fails
5. For each assertion `a` in `AuthenticationResponse.assertions`
   1. Parse TLV data from `a.assertion` assuming it is encoded according to the suspected assertion scheme `a.assertionScheme` and make sure it contains all mandatory fields (indicated in authenticator Metadata) it is supposed to have and has a valid syntax.
      - If it doesn't - continue with next assertion
   2. Retrieve the AAID from the assertion.
      Note

      The AAID in `TAG_UAFV1_SIGNED_DATA` is contained in `a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.TAG_AAID`.

   3. Verify that `a.assertionScheme` matches `Metadata(AAID).assertionScheme`
      - If it doesn't match - continue with next assertion
   4. Make sure that the AAID indeed matches the policy of the Authentication Request
      - If it doesn't meet the policy – continue with next assertion
   5. if `a.assertion` contains an object of type `TAG_UAFV1_AUTH_ASSERTION`, then
      1. if `a.assertion.TAG_UAFV1_AUTH_ASSERTION` contains `TAG_UAFV1_SIGNED_DATA` as first element:
         1. Obtain `Metadata(AAID).AuthenticatorVersion` for this AAID and make sure that it is lower or equal to `a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.TAG_ASSERTION_INFO.AuthenticatorVersion`.
            - If `Metadata(AAID).AuthenticatorVersion` is higher (i.e. the authenticator firmware is outdated), it is RECOMMENDED to assume increased authentication risk. See "StatusReport dictionary" and "Metadata TOC object Processing Rules" in [FIDOMetadataService] for more details on this.
         2. Retrieve `a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.TAG_KEYID` as KeyID
         3. Locate `UAuth.pub` public key associated with (AAID, KeyID) in the user's record.
            - If such record doesn't exist - continue with next assertion
         4. Verify the AAID against the AAID stored in the user's record at time of Registration.
            - If comparison fails – continue with next assertion
         5. Locate authenticator specific authentication algorithms from authenticator metadata (field `AuthenticationAlgs`)
         6. Check the Signature Counter `a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.SignCounter` and make sure it is either not supported by the authenticator (i.e. the value provided and the value stored in the user's record are both 0 or the value isKeyRestricted is set to 'false' in the related Metadata Statement) or it has been incremented (compared to the value stored in the user's record)
            - If it is greater than 0, but didn't increment - continue with next assertion (as this is a cloned authenticator or a cloned authenticator has been used previously).
         7. Hash `AuthenticationResponse.FinalChallengeParams` using the hashing algorithm suitable for this authenticator type. Look up the hash algorithm in authenticator Metadata, field `AuthenticationAlgs`. It is the hash algorithm associated with the first entry related to a constant with prefix ALG_SIGN.
            - `FCHash = hash(AuthenticationResponse.FinalChallengeParams)`
         8. Make sure that `a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.TAG_FINAL_CHALLENGE_HASH` == `FCHash`
         - If comparison fails – continue with next assertion
         9. If `a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.TAG_ASSERTION_INFO.authenticationMode` == `2`
            Note

            The transaction hash included in this `AuthenticationResponse` must match the transaction content specified in the related `AuthenticationRequest`. As FIDO doesn’t mandate any specific FIDO Server API, the transaction content could be cached by any relying party software component, e.g. the FIDO Server or the relying party Web Application.

            1. Make sure there is a transaction cached on Relying Party side.
               - If not – continue with next assertion
            2. Go over all cached forms of the transaction content (potentially multiple cached PNGs for the same transaction) and calculate their hashes using hashing algorithm suitable for this authenticator (same hash algorithm as used for FinalChallenge).
               - For each `cachedTransaction` add `hash(cachedTransaction)` into `cachedTransactionHashList`
            3. Make sure that `a.TransactionHash` is in `cachedTransactionHashList`
               - If it's not in the list – continue with next assertion
         10. Use `UAuth.pub` key and appropriate authentication algorithm to verify `a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_SIGNATURE`
             1. If signature verification fails – continue with next assertion
             2. Update `SignCounter` in user's record with `a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.SignCounter`
      2. if `a.assertion.TAG_UAFV1_AUTH_ASSERTION` contains a different object than `TAG_UAFV1_SIGNED_DATA` as first element, then follow the rules specific to that object.
   6. if `a.assertion` doesn't contain an object of type `TAG_UAFV1_AUTH_ASSERTION`, then skip this assertion (as in this UAF v1 only `TAG_UAFV1_AUTH_ASSERTION` is defined).
   7. Treat this assertion `a` as positively verified.
6. Process all positively verified authentication assertions `a`.

### 3.6 Deregistration Operation

This operation allows FIDO Server to ask the FIDO Authenticator to delete keys related to the particular relying party.

The FIDO Server MAY explicitly enumerate the keys to be deleted, or the FIDO server MAY signal deregistration of all keys on all authenticators managed by the FIDO UAF Client and relating to a given appID.

Note
There are various deregistration use cases that both FIDO Server and FIDO Client implementations should allow for. Two in particular are:

1. FIDO Servers should trigger this operation in the event a user removes their account at the relying party.
2. FIDO Clients should ensure that relying party application facets -- e.g., mobile apps, web pages -- have means to initiate a deregistration operation without having necessarily received a UAF protocol message with an `op` value of "Dereg". This allows the relying party app facet to remove a user's keys from authenticators during events such as relying party app removal or installation.

#### 3.6.1 Deregistration Request Message

The FIDO UAF Deregistration request message is represented as an array of dictionaries. The array MUST contain exactly one dictionary. The request is defined as DeregistrationRequest dictionary.

Example 12: UAF Deregistration Request

    [{
        "header": {
          "op": "Dereg",
          "upv": {
            "major": 1,
            "minor": 1
          },
      "appID": "https://uaf-test-1.noknoktest.com:8443/SampleApp/uaf/facets"
        },
        "authenticators": [
          {
            "aaid": "ABCD#ABCD",
            "keyID": ""
          }
        ]
    }]

The example above contains a version 1.1 deregistration request. This request will deregister all keys registered in authenticator with `aaid` "ABCD#ABCD" for the given `appID`.
Note

There is no deregistration response object.

#### 3.6.2 DeregisterAuthenticator dictionary

    dictionary DeregisterAuthenticator {
        required AAID  aaid;
        required KeyID keyID;
    };

##### 3.6.2.1 Dictionary `DeregisterAuthenticator` Members

`aaid` of type required AAID
  AAID of the authenticator housing the `UAuth.priv` key to deregister, or an empty string if all keys related to the specified `appID` are to be de-registered.
`keyID` of type required KeyID
  The unique KeyID related to `UAuth.priv`. KeyID is assumed to be unique within the scope of an AAID only. If `aaid` is not an empty string, then:
  1. `keyID` MAY contain a value of type KeyID, or,
  2. `keyID` MAY be an empty string.
  (1) signals deletion of a particular `UAuth.priv` key mapped to the (`AAID`, `KeyID`) tuple.
  (2) signals deletion of all KeyIDs associated with the specified `aaid`.
  If `aaid` is an empty string, then `keyID` MUST also be an empty string. This signals deregistration of all keys on all authenticators that are mapped to the specified `appID`.

#### 3.6.3 DeregistrationRequest dictionary

    dictionary DeregistrationRequest {
        required OperationHeader           header;
        required DeregisterAuthenticator[] authenticators;
    };

##### 3.6.3.1 Dictionary `DeregistrationRequest` Members

`header` of type required OperationHeader
  `Header.op` MUST be "Dereg".
`authenticators` of type array of required DeregisterAuthenticator
  List of authenticators to be deregistered.

#### 3.6.4 Deregistration Processing Rules

##### 3.6.4.1 Deregistration Request Generation Rules for FIDO Server

The FIDO Server MUST follow the steps:

1. Create a `DeregistrationRequest` message `m` with `m.header.upv` set to the appropriate version number.
2. If the FIDO Server intends to deregister all keys on all authenticators managed by the FIDO UAF Client for this `appID`, then:
   1. create one and only one `DeregisterAuthenticator` object `o`
   2. Set `o.aaid` and `o.keyID` to be empty string values
   3. Append `o` to `m.authenticators`, and go to step 5
3. If the FIDO Server intends to deregister all keys on all authenticators with a given AAID managed by the FIDO UAF Client for this `appID`, then:
   1. create one and only one `DeregisterAuthenticator` object `o`
   2. Set `o.aaid` to the intended AAID and set `o.keyID` to be an empty string.
   3. Append `o` to `m.authenticators`, and go to step 5
4. Otherwise, if the FIDO Server intends to deregister specific (`AAID`, `KeyID`) tuples, then for each tuple to be deregistered:
   1. create a `DeregisterAuthenticator` object `o`
   2. Set `o.aaid` and `o.keyID` appropriately
   3. Append `o` to `m.authenticators`
5. delete related entry (or entries) in FIDO Server's account database
6. Send message to FIDO UAF Client

##### 3.6.4.2 Deregistration Request Processing Rules for FIDO UAF Client

The FIDO UAF Client MUST follow the steps:

1. Choose the message `m` with upv set to the appropriate version number.
2. Parse the message
   - If a mandatory field in `DeregistrationRequest` message is not present or a field doesn't correspond to its type and value – reject the operation
   - Empty string values for `o.aaid` and `o.keyID` MUST occur in the first and only DeregisterAuthenticator object o, otherwise reject the operation
3. Obtain `FacetID` of the requesting Application. If the `AppID` is missing or empty, set the `AppID` to the `FacetID`.

   Verify that the `FacetID` is authorized for the `AppID` according to the algorithms in [FIDOAppIDAndFacets].

   - If the `FacetID` of the requesting Application is not authorized, reject the operation
4. For each authenticator compatible with the message version `DeregistrationRequest.header.upv` and having an AAID matching one of the provided `AAID`s (an AAID of an authenticator matches if it is either (a) equal to one of the `AAID`s in the `DeregistrationRequest` or if (b) the `AAID` in the `DeregistrationRequest` is an empty string):
   1. Create appropriate `ASMRequest` for Deregister function and send it to the ASM. If the ASM returns an error, handle that error appropriately. The status code returned by the ASM [UAFASM] must be mapped to a status code defined in [UAFAppAPIAndTransport] as specified in section 3.4.6.2.1 Mapping ASM Status Codes to ErrorCode.

##### 3.6.4.3 Deregistration Request Processing Rules for FIDO Authenticator

See [UAFASM] section "Deregister request".

## 4. Considerations

This section is non-normative.

### 4.1 Protocol Core Design Considerations

This section describes the important design elements used in the protocol.

#### 4.1.1 Authenticator Metadata

It is assumed that FIDO Server has access to a list of all supported authenticators and their corresponding Metadata. Authenticator metadata [FIDOMetadataStatement] contains information such as:

- Supported Registration and Authentication Schemes
- Authentication Factor, Installation type, supported content-types and other supplementary information, etc.

In order to make a decision about which authenticators are appropriate for a specific transaction, FIDO Server looks up the list of authenticator metadata by AAID and retrieves the required information from it.

Each entry in the authenticator metadata repository MUST be identified with a unique authenticator Attestation ID (AAID).

#### 4.1.2 Authenticator Attestation

Authenticator Attestation is the process of validating authenticator model identity during registration. It allows Relying Parties to cryptographically verify that the authenticator reported by FIDO UAF Client is really what it claims to be.

Using authenticator Attestation, a relying party "example-rp.com" will be able to verify that the authenticator model of the "example-Authenticator", reported with AAID "1234#5678", is not malware running on the FIDO User Device but is really a authenticator of model "1234#5678".

FIDO Authenticators SHOULD support "Basic Attestation" or "ECDAA" described below. New Attestation mechanisms may be added to the protocol over time.

FIDO Authenticators not providing sufficient protection for Attestation keys (non-attested authenticators) MUST use the UAuth.priv key in order to formally generate the same KeyRegistrationData object as attested authenticators. This behavior MUST be properly declared in the Authenticator Metadata.

##### 4.1.2.1 Basic Attestation

There are two different flavors of Basic Attestation:

Full Basic Attestation
  Based on an attestation private key shared among a class of authenticators (e.g. same model).
Surrogate Basic Attestation
  Just syntactically a Basic Attestation. The attestation object self-signed, i.e. it is signed using the UAuth.priv key, i.e. the key corresponding to the UAuth.pub key included in the attestation object. As a consequence it does not provide a cryptographic proof of the security characteristics. But it is the best thing we can do if the authenticator is not able to have an attestation private key.

###### 4.1.2.1.1 Full Basic Attestation

Note

FIDO Servers must have access to a trust anchor for verifying attestation public keys (i.e. Attestation Certificate trust store) in order to follow the assumptions made in [FIDOSecRef]. Authenticators must provide its attestation signature during the registration process for the same reason. The attestation trust anchor is shared with FIDO Servers out of band (as part of the Metadata). This sharing process shouldt be done according to [FIDOMetadataService].

Note

The protection measures of the Authenticator's attestation private key depend on the specific authenticator model's implementation.

Note

The FIDO Server must load the appropriate Authenticator Attestation Root Certificate from its trust store based on the AAID provided in KeyRegistrationData object.

In this Full Basic Attestation model, a large number of authenticators must share the same Attestation certificate and Attestation Private Key in order to provide non-linkability (see Protocol Core Design Considerations). Authenticators can only be identified on a production batch level or an AAID level by their Attestation Certificate, and not individually. A large number of authenticators sharing the same Attestation Certificate provides better privacy, but also makes the related private key a more attractive attack target.

Note

When using Full Basic Attestation: A given set of authenticators sharing the same manufacturer and essential characteristics must not be issued a new Attestation Key before at least 100,000 devices are issued the previous shared key.

Fig. 10 Attestation Certificate Chain

###### 4.1.2.1.2 Surrogate Basic Attestation

In this attestation method, the UAuth.priv key MUST be used to sign the Registration Data object. This behavior MUST be properly declared in the Authenticator Metadata.

Note

FIDO Authenticators not providing sufficient protection for Attestation keys (non-attested authenticators) must use this attestation method.

##### 4.1.2.2 Direct Anonymous Attestation (ECDAA)

The FIDO Basic Attestation scheme uses attestation "group" keys shared across a set of authenticators with identical characteristics in order to preserve privacy by avoiding the introduction of global correlation handles. If such an attestation key is extracted from one single authenticator, it is possible to create a "fake" authenticator using the same key and hence indistinguishable from the original authenticators by the relying party. Removing trust for registering new authenticators with the related key would affect the entire set of authenticators sharing the same "group" key. Depending on the number of authenticators, this risk might be unacceptable high.

This is especially relevant when the attestation key is primarily protected against malware attacks as opposed to targeted physical attacks.

An alternative approach to "group" keys is the use of individual keys combined with a Privacy-CA [TPMv1-2-Part1]. Translated to FIDO, this approach would require one Privacy-CA interaction for each Uauth key. This means relatively high load and high availability requirements for the Privacy-CA. Additionally the Privacy-CA aggregates sensitive information (i.e. knowing the relying parties the user interacts with). This might make the Privacy-CA an interesting attack target.

Another alternative is the Direct Anonymous Attestation [BriCamChe2004-DAA]. Direct Anonymous Attestation is a cryptographic scheme combining privacy with security. It uses the Authenticator specific secret once to communicate with a single DAA Issuer (either at manufacturing time or after being sold before first use) and uses the resulting DAA credential in the DAA-Sign protocol with each relying party. The (original) DAA scheme has been adopted by the Trusted Computing Group for TPM v1.2 [TPMv1-2-Part1].

ECDAA (see [FIDOEcdaaAlgorithm] for details) is an improved DAA scheme based on elliptic curves and bilinear pairings [CheLi2013-ECDAA]. This scheme provides significantly improved performance compared with the original DAA and it is part of the TPMv2 specification [TPMv2-Part1].

The ECDAA attestation algorithm is used as specified in [FIDOEcdaaAlgorithm].

#### 4.1.3 Error Handling

Note

FIDO Servers must inform the calling Relying Party Web Application Server (see FIDO Interoperability Overview) about any error conditions encountered when generating or processing UAF messages through their proprietary API.

FIDO Authenticators MUST inform the FIDO UAF Client (see FIDO Interoperability Overview) about any error conditions encountered when processing commands through the Authenticator Specific Module (ASM). See [UAFASM] and [UAFAuthnrCommands] for details.

#### 4.1.4 Assertion Schemes

UAF Protocol is designed to be compatible with a variety of existing authenticators (TPMs, Fingerprint Sensors, Secure Elements, etc.) and also future authenticators designed for FIDO. Therefore extensibility is a core capability designed into the protocol.

It is considered that there are two particular aspects that need careful extensibility. These are:

- Cryptographic key provisioning (KeyRegistrationData)
- Cryptographic authentication and signature (SignedData)

The combination of KeyRegistrationData and SignedData schemes is called an Assertion Scheme.

The UAF protocol allows plugging in new Assertion Schemes. See also UAF Supported Assertion Schemes.

The Registration Assertion defines how and in which format a cryptographic key is exchanged between the authenticator and the FIDO Server.

The Authentication Assertion defines how and in which format the authenticator generates a cryptographic signature.

The generally-supported Assertion Schemes are defined in [UAFRegistry].

#### 4.1.5 Username in Authenticator

FIDO UAF supports authenticators acting as first authentication factor (i.e. replacing username and password). As part of the FIDO UAF Registration, the Uauth key is registered (linked) to the related user account at the RP. The authenticator stores the username (allowing the user to select a specific account at the RP in the case he has multiple ones). See [UAFAuthnrCommands], section "Sign Command" for details.

#### 4.1.6 Silent Authenticators

FIDO UAF supports authenticators not requiring any types of user verification or user presence check. Such authenticators are called Silent Authenticators.

In order to meet user's expectations, such Silent Authenticators need specific properties:

- It must be possible for a user to effectively remove a Uauth key maintained by a Silent Authenticator (in order to avoid being tracked) at the user's discretion (see [UAFAuthnrCommands]). This is not compatible with statelesss implementations storing the Uauth private key wrapped inside a KeyHandle on the FIDO Server.
- TransactionConfirmation is not supported (as it would require user input which is not intended), see [UAFAuthnrCommands].
- They might not operate in first factor mode (see [UAFAuthnrCommands]) as this might violate the privacy principles.

The MetadataStatement has to truthfully reflect the Silent Authenticator, i.e. field userVerification needs to be set to USER_VERIFY_NONE.

#### 4.1.7 TLS Protected Communication

Note

In order to protect the data communication between FIDO UAF Client and FIDO Server a protected TLS channel must be used by FIDO UAF Client (or User Agent) and the Relying Party for all protocol elements.

1. The server endpoint of the TLS connection must be at the Relying Party
2. The client endpoint of the TLS connection must be either the FIDO UAF Client or the User Agent / App
3. TLS Client and Server should use TLS v1.2 or newer and should only use TLS v1.1 if TLS v1.2 or higher are not available. The "anon" and "null" TLS crypto suites are not allowed and must be rejected; insecure crypto-algorithms in TLS (e.g. MD5, RC4, SHA1) should be avoided [[SP 800-131A]] [RFC7525].
4. TLS Extended Master Secret Extension [RFC7627] and TLS Renegotiation Indication Extension [RFC5746] should be used to protect against MITM attacks.
5. The use of the tls-unique method is deprecated as its security is broken, see [TLSAUTH].

We recommend, that the

1. TLS Client verifies and validates the server certificate chain according to [RFC5280], section 6 "Certificate Path Validation". The certificate revocation status should be checked (e.g. using OCSP [RFC2560] or CRL based validation [RFC5280]) and the TLS server identity should be checked as well [RFC6125].
2. TLS Client's trusted certificate root store is properly maintained and at least requires the CAs included in the root store to annually pass Web Trust or ETSI (ETSI TS 101 456, or ETSI TS 102 042) audits for SSL CAs.

See [TR-03116-4] and [SHEFFER-TLS] for more recommendations on how to use TLS.

### 4.2 Implementation Considerations

#### 4.2.1 Server Challenge and Random Numbers

Note

A `ServerChallenge` needs appropriate random sources in order to be effective (see [RFC4086] for more details). The (pseudo-)random numbers used for generating the Server Challenge should successfully pass the randomness test specified in [Coron99] and they should follow the guideline given in [SP800-90b].

### 4.3 Security Considerations

There is no "one size fits all" authentication method. The FIDO goal is to decouple the user verification method from the authentication protocol and the authentication server, and to support a broad range of user verification methods and a broad range of assurance levels. FIDO authenticators should be able to leverage capabilities of existing computing hardware, e.g. mobile devices or smart cards.

The overall assurance level of electronic user authentications highly depends (a) on the security and integrity of the user's equipment involved and (b) on the authentication method being used to authenticate the user.

When using FIDO, users should have the freedom to use any available equipment and a variety of authentication methods. The relying party needs reliable information about the security relevant parts of the equipment and the authentication method itself in order to determine whether the overall risk of an electronic authentication is acceptable in a particular business context. The FIDO Metadata Service [FIDOMetadataService] is intended to provide such information.

It is important for the UAF protocol to provide this kind of reliable information about the security relevant parts of the equipment and the authentication method itself to the FIDO server.

The overall security is determined by the weakest link. In order to support scalable security in FIDO, the underlying UAF protocol needs to provide a very high conceptual security level, so that the protocol isn't the weakest link.

Relying Parties define Acceptable Assurance Levels. The FIDO Alliance envisions a broad range of FIDO UAF Clients, FIDO Authenticators and FIDO Servers to be offered by various vendors. Relying parties should be able to select a FIDO Server providing the appropriate level of security. They should also be in a position to accept FIDO Authenticators meeting the security needs of the given business context, to compensate assurance level deficits by adding appropriate implicit authentication measures, and to reject authenticators not meeting their requirements. FIDO does not mandate a very high assurance level for FIDO Authenticators, instead it provides the basis for authenticator and user verification method competition.

Authentication vs. Transaction Confirmation. Existing Cloud services are typically based on authentication. The user launches an application (i.e. User Agent) assumed to be trusted and authenticates to the Cloud service in order to establish an authenticated communication channel between the application and the Cloud service. After this authentication, the application can perform any actions to the Cloud service using the authenticated channel. The service provider will attribute all those actions to the user. Essentially the user authenticates all actions performed by the application in advance until the service connection or authentication times out. This is a very convenient way as the user doesn't get distracted by manual actions required for the authentication. It is suitable for actions with low risk consequences.

However, in some situations it is important for the relying party to know that a user really has seen and accepted a particular content before he authenticates it. This method is typically being used when non-repudiation is required. The resulting requirement for this scenario is called What You See Is What You Sign (WYSIWYS).

UAF supports both methods; they are called "Authentication" and "Transaction Confirmation". The technical difference is, that with Authentication the user confirms a random challenge, where in the case of Transaction Confirmation the user also confirms a human readable content, i.e. the contract. From a security point, in the case of authentication the application needs to be trusted as it performs any action once the authenticated communication channel has been established. In the case of Transaction Confirmation only the transaction confirmation display component implementing WYSIWYS needs to be trusted, not the entire application.

Distinct Attestable Security Components. For the relying party in order to determine the risk associated with an authentication, it is important to know details about some components of the user's environment. Web Browsers typically send a "User Agent" string to the web server. Unfortunately any application could send any string as "User Agent" to the relying party. So this method doesn't provide strong security. FIDO UAF is based on a concept of cryptographic attestation. With this concept, the component to be attested owns a cryptographic secret and authenticates its identity with this cryptographic secret. In FIDO UAF the cryptographic secret is called "Authenticator Attestation Key". The relying party gets access to reference data required for verifying the attestation.

In order to enable the relying party to appropriately determine the risk associated with an authentication, all components performing significant security functions need to be attestable.

In FIDO UAF significant security functions are implemented in the "FIDO Authenticators". Security functions are:

1. Protecting the attestation key.
2. Generating and protecting the Authentication key(s), typically one per relying party and user account on relying party.
3. Verifying the user.
4. Providing the WYSIWYS capability ("Transaction Confirmation Display" component).

Some FIDO Authenticators might implement these functions in software running on the FIDO User Device, others might implement these functions in "hardware", i.e. software running on a hardware segregated from the FIDO User Device. Some FIDO Authenticators might even be formally evaluated and accredited to some national or international scheme. Each FIDO Authenticator model has an attestation ID (AAID), uniquely identifying the related security characteristics. Relying parties get access to these security properties of the FIDO Authenticators and the reference data required for verifying the attestation.

Resilience to leaks from other verifiers. One of the important issues with existing authentication solutions is a weak server side implementation, affecting the security of authentication of typical users to other relying parties. It is the goal of the FIDO UAF protocol to decouple the security of different relying parties.

Decoupling User Verification Method from Authentication Protocol. In order to decouple the user verification method from the authentication protocol, FIDO UAF is based on an extensible set of cryptographic authentication algorithms. The cryptographic secret will be unlocked after user verification by the Authenticator. This secret is then used for the authenticator-to-relying party authentication. The set of cryptographic algorithms is chosen according to the capabilities of existing cryptographic hardware and computing devices. It can be extended in order to support new cryptographic hardware.

Privacy Protection. Different regions in the world have different privacy regulations. The FIDO UAF protocol should be acceptable in all regions and hence must support the highest level of data protection. As a consequence, FIDO UAF doesn't require transmission of biometric data to the relying party nor does it require the storage of biometric reference data [ISOBiometrics] at the relying party. Additionally, cryptographic secrets used for different relying parties shall not allow the parties to link actions to the same user entity. UAF supports this concept, known as non-linkability. Consequently, the UAF protocol doesn't require a trusted third party to be involved in every transaction.

Relying parties can interactively discover the AAIDs of all enabled FIDO Authenticators on the FIDO User Device using the Discovery interface [UAFAppAPIAndTransport]. The combination of AAIDs adds to the entropy provided by the client to relying parties. Based on such information, relying parties can fingerprint clients on the internet (see Browser Uniqueness at eff.org and https://wiki.mozilla.org/Fingerprinting). In order to minimize the entropy added by FIDO, the user can enable/disable individual authenticators – even when they are embedded in the device (see [UAFAppAPIAndTransport], section "privacy considerations").

#### 4.3.1 FIDO Authenticator Security

See [UAFAuthnrCommands].

#### 4.3.2 Cryptographic Algorithms

In order to keep key sizes small and to make private key operations fast enough for small devices, it is suggested that implementers prefer ECDSA [ECDSA-ANSI] in combination with SHA-256 / SHA-512 hash algorithms. However, the RSA algorithm is also supported. See [FIDORegistry] "Authentication Algorithms" and "Public Key Representation Formats" for a list of generally supported cryptographic algorithms.

One characteristic of ECDSA is that it needs to produce, for each signature generation, a fresh random value. For effective security, this value must be chosen randomly and uniformly from a set of modular integers, using a cryptographically secure process. Even slight biases in that process may be turned into attacks on the signature schemes.

Note

If such random values cannot be provided under all possible environmental conditions, then a deterministic version of ECDSA should be used (see [RFC6979]).

#### 4.3.3 FIDO Client Trust Model

The FIDO environment on a FIDO User Device comprises 4 entities:

- User Agents (a native app or a browser)
- FIDO UAF Clients (a shared service potentially used by multiple User Agents)
- Authenticator Specific Modules (ASMs)
- Authenticators

Fig. 11 UAF Client Trust Model

The security and privacy principles that underpin mobile operating systems require certain behaviours from apps. FIDO must uphold those principles wherever possible. This means that each of these components has to enforce specific trust relationships with the others to avoid the risk of rogue components subverting the integrity of the solution.

One specific requirement on handsets is that apps originating from different vendors must not be allowed directly to view or edit each other’s data (e.g. FIDO UAF credentials).

Given that FIDO UAF Clients are intended to provide a shared service, the principle of siloed app data has been applied to the FIDO UAF Client, rather than individual apps. This means that if two or more FIDO UAF Clients are present on a device, then each FIDO UAF Client is unable to access authentication keys created by another FIDO UAF Client. A given FIDO UAF Client may however provide services to multiple User Agents, so that the same authentication key can authenticate to different facets of the same Relying Party, even if one facet is a 3rd party browser.

This exclusive access restriction is enforced through the KHAccessToken. When a FIDO UAF Client communicates with an ASM, the ASM reads the identity of the FIDO UAF Client caller1 and includes that Client ID in the KHAccessToken that it sends to the authenticator. Subsequent calls to the authenticator must include the same Client ID in the KHAccessToken. Each authentication key is also bound to the ASM that created it, by means of an ASMToken (a random unique ID for the ASM) that is also included in the KHAccessToken.

Finally, the User Agents that a FIDO UAF Client will recognise are determined by the Relying Party itself. The FIDO UAF Client requests a list of Trusted Apps from the RP as part of the Registration and Authentication protocols. This prevents User Agents that have not been explicitly authorized by the Relying Party from using the FIDO credentials.

In this manner, in a compliant FIDO installation, UAF credentials can only be accessed via apps that the relying party explicitly trusts and through the same client and ASM that performed the original registration.

It should be noted that the specification allows for FIDO UAF Clients to be built directly into User Agents. However, such implementations will restrict the ability to support multiple facets for relying party applications unless they also expose the UAF Client API for other User Agents to consume.

##### 4.3.3.1 Isolation using KHAccessToken

Authenticators might be implemented in dedicated hardware and hence might not be able to verify the calling software entity (i.e. the ASM).

The KHAccessToken allows restricting access to the keys generated by the FIDO Authenticator to the intended ASM. It is based on a Trust On First Use (TOFU) concept.

FIDO Authenticators are capable of binding UAuth.Key with a key provided by the caller (i.e. the ASM). This key is called KHAccessToken.

This technique allows making sure that registered keys are only accessible by the caller that originally registered them. A malicious App on a mobile platform won't be able to access keys by bypassing the related ASM (assuming that this ASM originally registered these keys).

The KHAccessToken is typically specific to the AppID, PersonaID, ASMToken and the CallerID. See [UAFASM] for more details.

Note

On some platforms, the ASM additionally might need special permissions in order to communicate with the FIDO Authenticator. Some platforms do not provide means to reliably enforce access control among applications.

#### 4.3.4 TLS Binding

Various channel binding methods have been proposed (e.g. [RFC5929] and [ChannelID]).

UAF relies on TLS server authentication for binding authentication keys to AppIDs. There are threats:

1. Attackers might fraudulently get a TLS server certificate for the same AppID as the relying party and they might be able to manipulate the DNS system.
2. Attackers might be able to steal the relying party's TLS server private key and certificate and they might be able to manipulate the DNS system.

And there are functionality requirements:

1. UAF transactions might span across multiple TLS sessions. As a consequence, "tls-unique" defined in [RFC5929] might be difficult to implement.
2. Data centers might use SSL concentrators.
3. Data centers might implement load-balancing for TLS endpoints using different TLS certificates. As a consequence, "tls-server-end-point" defined in [RFC5929], i.e. the hash of the TLS server certificate might be inappropriate.
4. Unfortunately, hashing of the TLS server certificate (as in "tls-server-end-point") also limits the usefulness of the channel binding in a particular, but quite common circumstance. If the client is operated behind a trusted (to that client) proxy that acts as a TLS man-in-the-middle, your client will see a different certificate than the one the server is using. This is actually quite common on corporate or military networks with a high security posture that want to inspect all incoming and outgoing traffic. If the FIDO Server just gets a hash value, there's no way to distinguish this from an attack. If sending the entire certificate is acceptable from a performance perspective, the server can examine it and determine if it is a certificate for a valid name from a non-standard issuer (likely administratively trusted) or a certificate for a different name (which almost certainly indicates a forwarding attack).

See ChannelBinding dictionary for more details.

#### 4.3.5 Session Management

FIDO does not define any specific session management methods. However, several FIDO functions rely on a robust session management being implemented by the relying party's web application:

FIDO Registration
  A web application might trigger FIDO Registration after authenticating an existing user via legacy credentials. So the session is used to maintain the authentication state until the FIDO Registration is completed.
FIDO Authentication
  After success FIDO Authentication, the session is used to maintain the authentication state during the operations performed by the user agent or mobile app.

Best practices should be followed to implement robust session management (e.g. [OWASP2013]).

#### 4.3.6 Personas

FIDO supports unlinkability [AnonTerminology] of accounts at different relying parties by using relying party specific keys.

Sometimes users have multiple accounts at a particular relying party and even want to maintain unlinkability between these accounts.

Today, this is difficult and requires certain measures to be strictly applied.

FIDO does not want to add more complexity to maintaining unlinkability between accounts at a relying party.

In the case of roaming authenticators, it is recommended to use different authenticators for the various personas (e.g. "business", "personal"). This is possible as roaming authenticators typically are small and not excessively expensive.

In the case of bound authenticators, this is different. FIDO recommends the "Persona" concept for this situation.

All relevant data in an authenticator are related to one Persona (e.g. "business" or "personal"). Some administrative interface (not standardized by FIDO) of the authenticator may allow maintaining and switching Personas.

The authenticator MUST only "know" / "recognize" data (e.g. authentication keys, usernames, KeyIDs, …) related to the Persona being active at that time.

With this concept, the User can switch to the "Personal" Persona and register new accounts. After switching back to "Business" Persona, these accounts will not be recognized by the authenticator (until the User switches back to "Personal" Persona again).

In order to support the persona feature, the FIDO Authenticator-specific Module API [UAFASM] supports the use of a 'PersonaID' to identify the persona in use by the authenticator. How Personas are managed or communicated with the user is out of scope for FIDO.

#### 4.3.7 ServerData and KeyHandle

Data contained in the field serverData (see Operation Header dictionary) of UAF requests is sent to the FIDO UAF Client and will be echoed back to the FIDO Server as part of the related UAF response message.

Note

The FIDO Server should not assume any kind of implicit integrity protection of such data nor any implicit session binding. The FIDO Server must explicitly bind the serverData to an active session.

Note

In some situations, it is desirable to protect sensitive data such that it can be stored in arbitrary places (e.g. in serverData or in the KeyHandle). In such situations, the confidentiality and integrity of such sensitive data must be protected. This can be achieved by using a suitable encryption algorithm, e.g. AES with a suitable cipher mode, e.g. CBC or CTR [CTRMode]. This cipher mode needs to be used correctly. For CBC, for example, a fresh random IV for each encryption is required. The data might have to be padded first in order to obtain an integral number of blocks in length. The integrity protection can be achieved by adding a MAC or a digital signature on the ciphertext, using a different key than for the encryption, e.g. using HMAC [FIPS198-1]. Alternatively, an authenticated encryption scheme such as AES-GCM [SP800-38D] or AES-CCM [SP800-38C] could be used. Such a scheme provides both integrity and confidentiality in a single algorithm and using a single key.

Note

When protecting serverData, the MAC or digital signature computation should include some data that binds the data to its associated message, for example by re-including the challenge value in the authenticated serverData.

#### 4.3.8 Authenticator Information retrieved through UAF Application API vs. Metadata

Several authenticator properties (e.g. UserVerificationMethods, KeyProtection, TransactionConfirmationDisplay, ...) are available in the metadata [FIDOMetadataStatement] and through the FIDO UAF Application API. The properties included in the metadata are authoritative and are provided by a trusted source. When in doubt, decisions should be based on the properties retrieved from the Metadata as opposed to the data retrieved through the FIDO UAF Application API.

However, the properties retrieved through the FIDO UAF Application API provide a good "hint" what to expect from the Authenticator. Such "hints" are well suited to drive and optimize the user experience.

#### 4.3.9 Policy Verification

FIDO UAF Response messages do not include all parameters received in the related FIDO UAF request message into the to-be-signed object. As a consequence, any MITM could modify such entries.

FIDO Server will detect such changes if the modified value is unacceptable.

For example, a MITM could replace a generic policy by a policy specifying only the weakest possible FIDO Authenticator. Such a change will be detected by FIDO Server if the weakest possible FIDO Authenticator does not match the initial policy (see Registration Response Processing Rules and Authentication Response Processing Rules).

#### 4.3.10 Replay Attack Protection

The FIDO UAF protocol specifies two different methods for replay-attack protection:

1. Secure transport protocol (TLS)
2. Server Challenge.

The TLS protocol by itself protects against replay-attacks when implemented correctly [TLS].

Additionally, each protocol message contains some random bytes in the `ServerChallenge` field. The FIDO server should only accept incoming FIDO UAF messages which contain a valid `ServerChallenge` value. This is done by verifying that the `ServerChallenge` value, sent by the client, was previously generated by the FIDO server. See `FinalChallengeParams`.

It should also be noted that under some (albeit unlikely) circumstances, random numbers generated by the FIDO server may not be unique, and in such cases, the same `ServerChallenge` may be presented more than once, making a replay attack harder to detect.

#### 4.3.11 Protection against Cloned Authenticators

FIDO UAF relies on the UAuth.Key to be protected and managed by an authenticator with the security characteristics specified for the model (identified by the AAID). The security is better when only a single authenticator with that specific UAuth.Key instance exists. Consequently FIDO UAF specifies some protection measures against cloning of authenticators.

Firstly, if the UAuth private keys are protected by appropriate measures then cloning should be hard as such keys cannot be extracted easily.

Secondly, UAF specifies a Signature Counter (see Authentication Response Processing Rules and [UAFAuthnrCommands]). This counter is increased by every signature operation. If a cloned authenticator is used, then the subsequent use of the original authenticator would include a signature counter lower to or equal to the previous (malicious) operation. Such an incident can be detected by the FIDO Server.

#### 4.3.12 Anti-Fraud Signals

There is the potential that some attacker misuses a FIDO Authenticator for committing fraud, more specifically they would:

1. Register the authenticator to some relying party for one account
2. Commit fraud
3. Deregister the Authenticator
4. Register the authenticator to some relying party for another account
5. Commit fraud
6. Deregister the Authenticator
7. and so on...

Note

Authenticators might support a Registration Counter (`RegCounter`). The `RegCounter` will be incremented on each registration and hence might become exceedingly high in such fraud scenarios. See [UAFAuthnrCommands] for more details.

### 4.4 Interoperability Considerations

FIDO supports Web Applications, Mobile Applications and Native PC Applications. Such applications are referred to as FIDO enabled applications.

Fig. 12 FIDO Interoperability Overview

Web applications typically consist of the web application server and the related Web App. The Web App code (e.g. HTML and JavaScript) is rendered and executed on the client side by the User Agent. The Web App code talks to the User Agent via a set of JavaScript APIs, e.g. HTML DOM. The FIDO DOM API is defined in [UAFAppAPIAndTransport]. The protocol between the Web App and the Relying Party Web Application Server is typically proprietary.

Mobile Apps play the role of the User Agent and the Web App (Client). The protocol between the Mobile App and the Relying Party Web Application Server is typically proprietary.

Native PC Applications play the role of the User Agent, the Web App (Client). Those applications are typically expected to be independent from any particular Relying Party Web Application Server.

It is recommended for FIDO enabled applications to use the FIDO messages according to the format specified in this document.

It is recommended for FIDO enabled application to use the UAF HTTP Binding defined in [UAFAppAPIAndTransport].

Note

The KeyRegistrationData and SignedData objects [UAFAuthnrCommands] are generated and signed by the FIDO Authenticators and have to be verified by the FIDO Server. Verification will fail if the values are modified during transport.

The ASM API [UAFASM] specifies the standardized API to access authenticator Specific Modules (ASMs) on Desktop PCs and Mobile Devices.

The document [UAFAuthnrCommands] does not specify a particular protocol or API. Instead it lists the minimum data set and a specific message format which needs to be transferred to and from the FIDO Authenticator.

## 5. UAF Supported Assertion Schemes

This section is normative.

### 5.1 Assertion Scheme "UAFV1TLV"

This scheme is mandatory to implement for FIDO Servers. This scheme is mandatory to implement for FIDO Authenticators.

This Assertion Scheme allows the authenticator and the FIDO Server to exchange an asymmetric authentication key generated by the Authenticator.

This assertion scheme is using Tag Length Value (TLV) compact encoding to encode registration and authentication assertions generated by authenticators. This is the default assertion scheme for UAF protocol.

TAGs and Algorithms are defined in [UAFRegistry].

The authenticator MUST use a dedicated key pair (UAuth.pub/UAuth.priv) suitable for the authentication algorithm specified in the metadata statement [FIDOMetadataStatement] for each relying party. This key pair SHOULD be generated as part of the registration operation.

Conforming FIDO Servers MUST implement all authentication algorithms and key formats listed in document [FIDORegistry] unless they are explicitly marked as optional in [FIDORegistry].

Conforming FIDO Servers MUST implement all attestation types (`TAG_ATTESTATION_*`) listed in document [UAFRegistry] unless they are explicitly marked as optional in [UAFRegistry].

Conforming authenticators MUST implement (at least) one attestation type defined in [UAFRegistry], as well as one authentication algorithm and one key format listed in [FIDORegistry].

#### 5.1.1 KeyRegistrationData

See [UAFAuthnrCommands], section "TAG_UAFV1_KRD".

#### 5.1.2 SignedData

See [UAFAuthnrCommands], section "TAG_UAFV1_SIGNED_DATA".

## 6. Definitions

See [FIDOGlossary].

## 7. Table of Figures

- Fig. 1 The UAF Architecture
- Fig. 2 UAF Registration Message Flow
- Fig. 3 Authentication Message Flow
- Fig. 4 Transaction Confirmation Message Flow
- Fig. 5 Deregistration Message Flow
- Fig. 6 UAF Registration Sequence Diagram
- Fig. 7 UAF Registration Cryptographic Data Flow
- Fig. 8 UAF Authentication Sequence Diagram
- Fig. 9 UAF Authentication Cryptographic Data Flow
- Fig. 10 Attestation Certificate Chain
- Fig. 11 UAF Client Trust Model
- Fig. 12 FIDO Interoperability Overview

## A. References

### A.1 Normative references

[ABNF]
  D. Crocker, Ed.; P. Overell. Augmented BNF for Syntax Specifications: ABNF. January 2008. Internet Standard. URL: https://tools.ietf.org/html/rfc5234
[ChannelID]
  D. Balfanz Transport Layer Security (TLS) Channel IDs. (Work In Progress) URL: http://tools.ietf.org/html/draft-balfanz-tls-channelid
[Coron99]
  J. Coron and D. Naccache An accurate evaluation of Maurer's universal test. LNCS 1556, February 1999, URL: http://www.jscoron.fr/publications/universal.pdf
[FIDOAppIDAndFacets]
  D. Balfanz, B. Hill, R. Lindemann, D. Baghdasaryan, FIDO AppID and Facets v1.0. FIDO Alliance Proposed Standard. URLs:
  HTML: fido-appid-and-facets-v1.1-id-20170202.pdf
[FIDOEcdaaAlgorithm]
  R. Lindemann, J. Camenisch, M. Drijvers, A. Edgington, A. Lehmann, R. Urian, FIDO ECDAA Algorithm. FIDO Alliance Implementation Draft. URLs:
  HTML: fido-ecdaa-v1.1-id-20170202.html
  PDF: fido-ecdaa-v1.1-id-20170202.pdf.
[FIDOGlossary]
  R. Lindemann, D. Baghdasaryan, B. Hill, J. Hodges, FIDO Technical Glossary. FIDO Alliance Implementation Draft. URLs:
  HTML: fido-glossary-v1.1-id-20170202.pdf
[FIDOMetadataStatement]
  B. Hill, D. Baghdasaryan, J. Kemp, FIDO Metadata Statements v1.0. FIDO Alliance Implementation Draft. URLs:
  HTML: fido-metadata-statements.pdf
[FIDORegistry]
  R. Lindemann, D. Baghdasaryan, B. Hill, FIDO Registry of Predefined Values. FIDO Alliance Implementation Draft. URLs:
  HTML: fido-registry-v1.1-id-20170202.pdf
[FIPS180-4]
  FIPS PUB 180-4: Secure Hash Standard (SHS). National Institute of Standards and Technology, March 2012, URL: http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf
[JWA]
  M. Jones. JSON Web Algorithms (JWA). May 2015. RFC. URL: https://tools.ietf.org/html/rfc7518
[JWK]
  M. Jones. JSON Web Key (JWK). May 2015. RFC. URL: https://tools.ietf.org/html/rfc7517
[RFC1321]
  R. Rivest, The MD5 Message-Digest Algorithm (RFC 1321), IETF, April 1992, URL: http://www.ietf.org/rfc/rfc1321.txt
[RFC2119]
  S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3629]
  F. Yergeau. UTF-8, a transformation format of ISO 10646. November 2003. Internet Standard. URL: https://tools.ietf.org/html/rfc3629
[RFC4086]
  D. Eastlake 3rd, J. Schiller, S. Crocker Randomness Requirements for Security (RFC 4086), IETF, June 2005, URL: http://www.ietf.org/rfc/rfc4086.txt
[RFC4627]
  D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON). July 2006. Informational. URL: https://tools.ietf.org/html/rfc4627
[RFC4648]
  S. Josefsson, The Base16, Base32, and Base64 Data Encodings (RFC 4648), IETF, October 2006, URL: http://www.ietf.org/rfc/rfc4648.txt
[RFC5056]
  N. Williams, On the Use of Channel Bindings to Secure Channels (RFC 5056), IETF, November 2007, URL: http://www.ietf.org/rfc/rfc5056.txt
[RFC5280]
  D. Cooper, S. Santesson, s. Farrell, S.Boeyen, R. Housley, W. Polk; Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF, May 2008, URL: http://www.ietf.org/rfc/rfc5280.txt
[RFC5929]
  J. Altman, N. Williams, L. Zhu, Channel Bindings for TLS (RFC 5929), IETF, July 2010, URL: http://www.ietf.org/rfc/rfc5929.txt
[RFC6234]
  D. Eastlake 3rd, T. Hansen, US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (RFC 6234), IETF, May 2011, URL: http://www.ietf.org/rfc/rfc6234.txt
[RFC6979]
  T. Pornin, Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) (RFC6979), IETF, August 2013, URL: http://www.ietf.org/rfc/rfc6979.txt
[SP800-90b]
  Elaine Barker and John Kelsey, NIST Special Publication 800-90b: Recommendation for the Entropy Sources Used for Random Bit Generation. National Institute of Standards and Technology, April 2016, URL: http://csrc.nist.gov/publications/drafts/800-90/draft-sp800-90b.pdf
[UAFASM]
  D. Baghdasaryan, J. Kemp, R. Lindemann, B. Hill, R. Sasson, FIDO UAF Authenticator-Specific Module API. FIDO Alliance Implementation Draft. URLs:
  HTML: fido-uaf-asm-api-v1.1-id-20170202.pdf
[UAFAppAPIAndTransport]
  B. Hill, D. Baghdasaryan, B. Blanke, FIDO UAF Application API and Transport Binding Specification. FIDO Alliance Implementation Draft. URLs:
  HTML: fido-uaf-client-api-transport-v1.1-id-20170202.pdf
[UAFAuthnrCommands]
  D. Baghdasaryan, J. Kemp, R. Lindemann, R. Sasson, B. Hill, FIDO UAF Authenticator Commands v1.0. FIDO Alliance Implementation Draft. URLs:
  HTML: fido-uaf-authnr-cmds-v1.1-id-20170202.pdf
[UAFRegistry]
  R. Lindemann, D. Baghdasaryan, B. Hill, FIDO UAF Registry of Predefined Values. FIDO Alliance Proposed Standard. URLs:
  HTML: fido-uaf-reg-v1.1-id-20170202.pdf
[WebIDL-ED]
  Cameron McCormack, Web IDL, W3C. Editor's Draft 13 November 2014. URL: http://heycam.github.io/webidl/

### A.2 Informative references

[AnonTerminology]
  "Anonymity, Unlinkability, Unobservability, Pseudonymity, and Identity Management - A Consolidated Proposal for Terminology", Version 0.34,. A. Pfitzmann and M. Hansen, August 2010. URL: http://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf
[BriCamChe2004-DAA]
  Ernie Brickell, Intel Corporation; Jan Camenisch, IBM Research; Liqun Chen, HP Laboratories, Direct Anonymous Attestation, 2004, URL: http://eprint.iacr.org/2004/205.pdf
[CTRMode]
  H. Lipmea, P. Rogaway, D. Wagner, Comments to NIST concerning AES Modes of Operation: CTR-Mode Encryption. National Institute of Standards and Technology, accessed March 11, 2014, URL: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ctr/ctr-spec.pdf
[CheLi2013-ECDAA]
  Liqun Chen, HP Laboratories and Jiangtao Li, Intel Corporation, Flexible and Scalable Digital Signatures in TPM 2.0, 2013. URL: http://dx.doi.org/10.1145/2508859.2516729
[ECDSA-ANSI]
  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
[FIDOMetadataService]
  R. Lindemann, B. Hill, D. Baghdasaryan, FIDO Metadata Service v1.0. FIDO Alliance Implementation Draft. URLs:
  HTML: fido-metadata-service-v1.1-id-20170202.pdf
[FIDOSecRef]
  R. Lindemann, D. Baghdasaryan, B. Hill, FIDO Security Reference. FIDO Alliance Implementation Draft. URLs:
  HTML: fido-security-ref-v1.1-id-20170202.pdf
[FIPS198-1]
  FIPS PUB 198-1: The Keyed-Hash Message Authentication Code (HMAC). National Institute of Standards and Technology, July 2008, URL: http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf
[ISOBiometrics]
  Project Editor, Harmonized Biometric Vocabulary. ISO/IEC 2382-37. 15 December 2012, URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c055194_ISOIEC_2382-37_2012.zip
[OWASP2013]
  OWASP 2013. OWASP Top 10 - 2013. The Ten Most Critical Web Application Security Risks
[RFC2560]
  M. Myers; R. Ankney; A. Malpani; S. Galperin; C. Adams. X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. June 1999. Proposed Standard. URL: https://tools.ietf.org/html/rfc2560
[RFC5746]
  E. Rescorla; M. Ray; S. Dispensa; N. Oskov. Transport Layer Security (TLS) Renegotiation Indication Extension. February 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5746
[RFC6125]
  P. Saint-Andre, J. Hodges, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (RFC 6125), IETF, March 2011, URL: http://www.ietf.org/rfc/rfc6125.txt
[RFC6287]
  D. M'Raihi, J. Rydell, S. Bajaj, S. Machani, D. Naccache, OCRA: OATH Challenge-Response Algorithm (RFC 6287), IETF, June 2011, URL: http://www.ietf.org/rfc/rfc6287.txt
[RFC7525]
  Y. Sheffer; R. Holz; P. Saint-Andre. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). May 2015. Best Current Practice. URL: https://tools.ietf.org/html/rfc7525
[RFC7627]
  K. Bhargavan, Ed.; A. Delignat-Lavaud; A. Pironti; A. Langley; M. Ray. Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension. September 2015. Proposed Standard. URL: https://tools.ietf.org/html/rfc7627
[SHEFFER-TLS]
  Y. Sheffer, R. Holz, P. Saint-Andre Recommendations for Secure Use of TLS and DTLS. Internet-Draft (Work in progress.) URL: https://tools.ietf.org/html/draft-sheffer-tls-bcp
[SP800-38C]
  M. Dworkin, NIST Special Publication 800-38C: Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality. National Institute of Standards and Technology, July 2007, URL: http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf
[SP800-38D]
  M. Dworkin. NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. November 2007 URL: https://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
[SP800-63]
  W. Burr, D. Dodson, E. Newton, R. Perlner, W.T. Polk, S. Gupta and E. Nabbus, NIST Special Publication 800-63-2: Electronic Authentication Guideline. National Institute of Standards and Technology, August 2013, URL: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf
[TLS]
  T. Dierks; E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. August 2008. Proposed Standard. URL: https://tools.ietf.org/html/rfc5246
[TLSAUTH]
  Karthikeyan Bhargavan; Antoine Delignat-Lavaud; Cédric Fournet; Alfredo Pironti; Pierre-Yves Strub. Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS. February 2014. URL: https://secure-resumption.com/tlsauth.pdf
[TPMv1-2-Part1]
  Trusted Computing Group, TPM 1.2 Part 1: Design Principles, URL: http://www.trustedcomputinggroup.org/files/static_page_files/72C26AB5-1A4B-B294-D002BC0B8C062FF6/TPM%20Main-Part%201%20Design%20Principles_v1.2_rev116_01032011.pdf
[TPMv2-Part1]
  Trusted Computing Group, Trusted Platform Module Library, Part 1: Architecture, URL: http://www.trustedcomputinggroup.org/files/static_page_files/8C56AE3E-1A4B-B294-D0F43097156A55D8/TPM%20Rev%202.0%20Part%201%20-%20Architecture%2001.16.pdf
[TR-03116-4]
  Technische Richtlinie TR-03116-4: eCard-Projekte der Bundesregierung: Teil 4 – Vorgaben für Kommunikationsverfahren im eGovernment. Bundesamt für Sicherheit in der Informationstechnik, 2013, URL: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116-4.pdf
[WebIDL]
  Cameron McCormack; Boris Zbarsky; Tobie Langel. Web IDL. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/