3.1.1.1 Attributes

major of type unsigned short, readonly

Major version.

minor of type unsigned short, readonly

Minor version.

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.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.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'ssignatureAlgorithm;
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.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.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.

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

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

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

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.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.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.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 AAIDs (an AAID of an authenticator matches if it is either (a) equal to one of the AAIDs 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".