Copyright © 2013-2017 FIDO Alliance All Rights Reserved.
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.
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 Implementation Draft. This document is intended to become a FIDO Alliance Proposed Standard. If you wish to make comments regarding this document, please Contact Us. All comments are welcome.
This Implementation Draft Specification has been prapared by FIDO Alliance, Inc. Permission is hereby granted to use the Specification solely for the purpose of implementing the Specification. No rights are granted to prepare derivative works of this Specification. Entities seeking permission to reproduce portions of this Specification for other uses must contact the FIDO Alliance to determine whether an appropriate license for such use is available.
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.
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: 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.
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].
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.
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:
The answers to these questions can be found in other UAF specifications, e.g. [UAFAppAPIAndTransport] [UAFASM] [UAFAuthnrCommands].
The following diagram depicts the entities involved in UAF protocol.
Of these entities, only these three directly create and/or process UAF protocol messages:
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.
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.
The following diagram shows the message flows for registration.
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.
The following diagram depicts the message flows for the authentication operation.
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.
The following figure depicts the transaction confirmation message flow.
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.
The following diagram depicts the deregistration message flow.
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.
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.
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].
This section is normative.
The FIDO UAF Client MUST follow the following rules while parsing server policy:
Policy.accepted is a list of combinations. Each combination
indicates a list of criteria for authenticators that the server
wants the user to register.Policy.accepted[][]. The lists
are ordered with highest priority first.Policy.disallowed criteriaPolicy.accepted is a list of combinations. Each
combination indicates a set of criteria which is enough to completely
authenticate the current pending operation
Policy.accepted[][]. The lists
are ordered with highest priority first.Policy.disallowed criteriaThis section is non-normative.
{
"accepted":
[
[{ "userVerification": 2, "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]}],
[{ "userVerification": 16, "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]}]
]
}{
"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.
{
"accepted": [ [{ "userVerification": 1042, "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]}] ]
}The next example requires two authenticators to be used:
{
"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:
{
"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:
{
"accepted":
[ [{ "vendorID": "1234", "authenticationAlgorithms": [1, 2, 5, 6], "assertionSchemes": ["UAFV1TLV"]}] ]
}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].
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:
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
[{upv1, asmVersion1}, {upv2, asmVersion1}, ...]
The ASM versions are retrieved from the AuthenticatorInfo.asmVersion field.
The UAF protocol version is derived from the related AuthenticatorInfo.assertionScheme field.
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).
Authnr_Version_Set) of version pairs
including authenticator supported asmVersion and the
compatible upv(s).
[{upv1, asmVersion1}, {upv2, asmVersion1}, ...]Authnr_Version_Set with FC_Version_Set
and select highest version pair from it.
upv is highest. In all these
pairs leave only the one with highest asmVersion.
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.
The Registration operation allows the FIDO Server and the FIDO Authenticator to agree on an authentication key.
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.
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.
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.
[{
"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"
]
}
]
}
}]RegistrationRequest contains a single, versioned, registration request.
dictionary RegistrationRequest {
required OperationHeader header;
required ServerChallenge challenge;
required DOMString username;
required Policy policy;
};RegistrationRequest Membersheader of type required OperationHeaderHeader.op MUST be "Reg"challenge of type required ServerChallengeusername of type required DOMStringstring[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 PolicyContains the authenticator's response to a RegistrationRequest message:
dictionary AuthenticatorRegistrationAssertion {
required DOMString assertionScheme;
required DOMString assertion;
DisplayPNGCharacteristicsDescriptor[] tcDisplayPNGCharacteristics;
Extension[] exts;
};AuthenticatorRegistrationAssertion MembersassertionScheme of type required DOMStringassertion. See
UAF Supported Assertion Schemes for details.
This assertionScheme is not part of a signed object and hence considered the suspected assertionScheme.
assertion of type required DOMStringbase64url(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 DisplayPNGCharacteristicsDescriptorexts of type array of ExtensionA 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.
[{
"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
}
}
}]Line breaks in fcParams have been inserted for improving readability.
Contains all fields related to the registration response.
dictionary RegistrationResponse {
required OperationHeader header;
required DOMString fcParams;
required AuthenticatorRegistrationAssertion[] assertions;
};RegistrationResponse Membersheader of type required OperationHeaderHeader.op MUST be "Reg".fcParams of type required DOMStringFinalChallengeParams
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
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:
p
m.
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.
m.aaid is not provided -
at least m.authenticationAlgorithms and
m.assertionSchemes MUST be providedm to v, e.g. v[j+1]=m.v to p.allowed, e.g. p.allowed[i+1]=vm[] for all disallowed Authenticators.
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.
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.
m for other disallowed criteria
(e.g. unsupported authenticationAlgs)m to p.disallowed.RegistrationRequest object r with
appropriate r.header for each supported version, and
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.
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.
r.challenger.usernamep to r.policy.r to the array o of message with various versions
(RegistrationRequest)o to the FIDO UAF ClientThe FIDO UAF Client MUST perform the following steps:
m with upv set to the appropriate version number.mRegRequest.policy.disallowed[].keyIDsFacetID 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].
FacetID of the requesting Application is not authorized, reject the operationFinalChallengeParams
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)))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.
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.
|
See [UAFAuthnrCommands], section "Register Command".
RegistrationResponse messageRegistrationRequest.header into RegistrationResponse.header
When the appID provided in the request was empty, the
FIDO Client must set the appID in this header to the facetID (see [FIDOAppIDAndFacets]).
RegistrationResponse.fcParams to FinalChallenge (base64url
encoded serialized and utf8 encoded FinalChallengeParams)RegistrationResponse.assertionsRegistrationResponse message to FIDO ServerThe 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:
RegistrationResponse.header.upv) is not
supported – reject the operationRegistrationResponse.header.serverData, if used,
passes any implementation-specific checks against its validity. See also section
ServerData and KeyHandle.
RegistrationResponse.fcParams and convert it
into an object (fcp)fcp.appID corresponds to the one stored by the FIDO Server
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.
fcp.facetID is in the list of trusted FacetIDs [FIDOAppIDAndFacets]fcp.channelBinding is as expected (see
section ChannelBinding dictionary)
There might be legitimate situations in which some methods of channel binding fail (see section 4.3.4 TLS Binding).
fcp.challenge has really been generated by the FIDO Server
for this operation and it is not expireda in RegistrationResponse.assertions
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.
The AAID in TAG_UAFV1_KRD is contained
in a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.TAG_AAID.
a.assertionScheme matches Metadata(AAID).assertionScheme
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.
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)a.assertion contains an object of type TAG_UAFV1_REG_ASSERTION, then
a.assertion.TAG_UAFV1_REG_ASSERTION contains
TAG_UAFV1_KRD as first element:
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).
a.assertion.TAG_UAFV1_REG_ASSERTION doesn't contain the
preferred attestation - it is RECOMMENDED to skip this
assertion and continue with next onea.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.FinalChallengeHash
== FCHash
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.
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.
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
a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.RegCounter
is exceedingly high, this assertion might be skipped
and processing will continue with next onea.assertion.TAG_UAFV1_REG_ASSERTION
contains TAG_ATTESTATION_BASIC_FULL tag
AttestationRootCertificates for the AAID in the
metadata [FIDOMetadataStatement] contains at least one element:
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.AttestationRootCertificates
for the AAID in authenticator Metadata, field AttestationRootCertificates.a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.TAG_ATTESTATION_BASIC_FULL.Signature
using the attestation certificate (obtained before).Metadata(AAID).AttestationRootCertificates for this AAID is
empty - continue with next assertiona.assertion.TAG_UAFV1_REG_ASSERTION
contains an object of type TAG_ATTESTATION_BASIC_SURROGATE
AttestationRootCertificates for the AAID in the
metadata is empty
a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_ATTESTATION_BASIC_SURROGATE.Signature
using a.assertion.TAG_UAFV1_REG_ASSERTION.TAG_UAFV1_KRD.TAG_PUB_KEY
AttestationRootCertificates for the AAID in the
metadata is not empty - continue with next assertion
(as the AAID obviously is expecting a different attestation method).a.assertion.TAG_UAFV1_REG_ASSERTION
contains an object of type TAG_ATTESTATION_ECDAA
ecdaaTrustAnchors for the AAID in the
metadata [FIDOMetadataStatement] contains at least one element:
ecdaaTrustAnchors entries, perform the
ECDAA Verify operation as specified in [FIDOEcdaaAlgorithm].
ecdaaTrustAnchors entryMetadata(AAID).ecdaaTrustAnchors for this AAID is
empty - continue with next assertiona.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).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.
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.
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).a
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).
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.
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.
Contains the Transaction Content provided by the FIDO Server:
dictionary Transaction {
required DOMString contentType;
required DOMString content;
DisplayPNGCharacteristicsDescriptor tcDisplayPNGCharacteristics;
};Transaction MemberscontentType of type required DOMStringThis version of the specification only supports the values
text/plain or image/png.
content of type required DOMStringbase64url(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 DisplayPNGCharacteristicsDescriptorUAF Authentication request message is represented as an array of dictionaries. The array MUST contain exactly one dictionary. The request is defined as AuthenticationRequest dictionary.
[{
"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
}
]
}
}]Contains the UAF Authentication Request Message:
dictionary AuthenticationRequest {
required OperationHeader header;
required ServerChallenge challenge;
Transaction[] transaction;
required Policy policy;
};AuthenticationRequest Membersheader of type required OperationHeaderHeader.op MUST be "Auth"challenge of type required ServerChallengetransaction of type array of TransactionThe 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 PolicyRepresents a response generated by a specific Authenticator:
dictionary AuthenticatorSignAssertion {
required DOMString assertionScheme;
required DOMString assertion;
Extension[] exts;
};AuthenticatorSignAssertion MembersassertionScheme of type required DOMStringassertion.
See UAF Supported Assertion Schemes for details.
This assertionScheme is not part of a signed object and hence considered the suspected assertionScheme.
assertion of type required DOMStringbase64url(byte[1..4096])
Contains the assertion containing a signature generated by UAuth.priv,
i.e. TAG_UAFV1_AUTH_ASSERTION.
exts of type array of ExtensionRepresents 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;
};AuthenticationResponse Membersheader of type required OperationHeaderHeader.op MUST be "Auth" fcParams of type required DOMStringassertions of type array of required AuthenticatorSignAssertionUAF Authentication response message is represented as an array of dictionaries. The array MUST contain exactly one dictionary. The response is defined as AuthenticationResponse dictionary.
[{
"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
}
}
}]Line breaks in fcParams have been inserted for improving readability.
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:
p
m.
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.
m.aaid is not provided -
at least m.authenticationAlgorithms and
m.assertionSchemes MUST be providedPolicy.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.m to v, e.g. v[j+1]=m.v to p.allowed, e.g. p.allowed[i+1]=vm[] for all disallowed authenticators.
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.
m for other disallowed criteria
(e.g. unsupported authenticationAlgs)m to p.disallowed.r with
appropriate r.header for the supported version, and
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.
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.
r.challenger.transaction.
AuthenticatorRegistrationAssertion.tcDisplayPNGCharacteristics during
Registration - it MUST be preferred over the (static) value specified in
the authenticator Metadata.
r.policy to our new policy object p created above,
e.g. r.policy = p.
The FIDO UAF Client MUST follow the steps:
m with upv set to the appropriate version number.m
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].
FacetID of the requesting Application is not authorized, reject the operationfcp 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)))AuthenticationRequest.header.upv (see Version Negotiation) and
user agrees to authenticate with:
AppID, FinalChallenge, Transactions (if present),
and all other fields to the ASMRequest.See [UAFAuthnrCommands], section "Sign Command".
The FIDO UAF Client MUST follow the steps:
AuthenticationRequest.header into AuthenticationResponse.header
When the appID provided in the request was empty, the
FIDO Client must set the appID in this header to the facetID (see [FIDOAppIDAndFacets]).
AuthenticationResponse.FinalChallengeParams with appropriate
fields and then stringify itAuthenticationResponse.assertionsThe 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:
AuthenticationResponse.header.upv) is not
supported – reject the operationAuthenticationResponse.header.serverData, if used, passes any
implementation-specific checks against its validity. See also section
ServerData and KeyHandle.
AuthenticationResponse.fcParams and convert into an
object (fcp)fcp.appID corresponds to the one stored by the FIDO Server
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.
fcp.facetID is in the list of trusted FacetIDs [FIDOAppIDAndFacets]ChannelBinding is as expected (see
section ChannelBinding dictionary)
There might be legitimate situations in which some methods of channel binding fail (see section 4.3.4 TLS Binding).
fcp.challenge has really been generated by the FIDO Server
for this operation and it is not expireda in AuthenticationResponse.assertions
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.
The AAID in TAG_UAFV1_SIGNED_DATA is contained
in a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.TAG_AAID.
a.assertionScheme matches Metadata(AAID).assertionScheme
a.assertion contains an object of type TAG_UAFV1_AUTH_ASSERTION, then
a.assertion.TAG_UAFV1_AUTH_ASSERTION contains TAG_UAFV1_SIGNED_DATA as first element:
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.
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.
a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.TAG_KEYID as KeyID
UAuth.pub public key associated
with (AAID, KeyID) in the user's record.
AuthenticationAlgs)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)
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)a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.TAG_FINAL_CHALLENGE_HASH
== FCHasha.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.TAG_ASSERTION_INFO.authenticationMode
== 2
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.
cachedTransaction add hash(cachedTransaction) into
cachedTransactionHashList
a.TransactionHash is in cachedTransactionHashList
UAuth.pub key and appropriate authentication algorithm to
verify a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_SIGNATURE
SignCounter in user's record with
a.assertion.TAG_UAFV1_AUTH_ASSERTION.TAG_UAFV1_SIGNED_DATA.SignCountera.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.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).a as positively verified.a.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.
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.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.
[{
"header": {
"op": "Dereg",
"upv": {
"major": 1,
"minor": 1
},
"appID": "https://uaf-test-1.noknoktest.com:8443/SampleApp/uaf/facets"
},
"authenticators": [
{
"aaid": "ABCD#ABCD",
"keyID": ""
}
]
}]aaid "ABCD#ABCD" for the given
appID.
There is no deregistration response object.
dictionary DeregisterAuthenticator {
required AAID aaid;
required KeyID keyID;
};DeregisterAuthenticator Membersaaid of type required AAIDUAuth.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 KeyIDUAuth.priv.
KeyID is assumed to be unique within the scope of an AAID only.
If aaid is not an empty string,
then:
keyID MAY contain a value of type
KeyID, or, keyID MAY be an
empty string. UAuth.priv key mapped
to the (AAID, KeyID) tuple. aaid. 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.
dictionary DeregistrationRequest {
required OperationHeader header;
required DeregisterAuthenticator[] authenticators;
};DeregistrationRequest Membersheader of type required OperationHeaderHeader.op MUST be "Dereg".
authenticators of type array of required DeregisterAuthenticatorThe FIDO Server MUST follow the steps:
DeregistrationRequest message m
with m.header.upv set to the appropriate version number.appID, then:
DeregisterAuthenticator object oo.aaid and o.keyID to be empty string valueso to m.authenticators, and go to step 5appID, then:
DeregisterAuthenticator object oo.aaid to the intended AAID and set
o.keyID to be an empty string.o to m.authenticators, and go to step 5AAID, KeyID) tuples, then
for each tuple to be deregistered:
DeregisterAuthenticator object oo.aaid and o.keyID appropriatelyo to m.authenticatorsThe FIDO UAF Client MUST follow the steps:
m with upv set to the appropriate version number.DeregistrationRequest message is not present
or a field doesn't correspond to its type and value – reject
the operationo.aaid and o.keyID MUST occur
in the first and only DeregisterAuthenticator object o, otherwise reject the operationFacetID 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].
FacetID of the requesting Application is not authorized, reject the operationDeregistrationRequest.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):
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.
See [UAFASM] section "Deregister request".
This section is non-normative.
This section describes the important design elements used in the protocol.
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:
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).
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.
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].
The protection measures of the Authenticator's attestation private key depend on the specific authenticator model's implementation.
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.
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.
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.
FIDO Authenticators not providing sufficient protection for Attestation keys (non-attested authenticators) must use this attestation method.
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].
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.
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:
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].
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.
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:
The MetadataStatement has to truthfully reflect the Silent Authenticator, i.e. field userVerification needs to be set to USER_VERIFY_NONE.
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.
See [TR-03116-4] and [SHEFFER-TLS] for more recommendations on how to use TLS.
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].
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:
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").
See [UAFAuthnrCommands].
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.
If such random values cannot be provided under all possible environmental conditions, then a deterministic version of ECDSA should be used (see [RFC6979]).
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.
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.
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.
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:
And there are functionality requirements:
See ChannelBinding dictionary for more details.
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:
Best practices should be followed to implement robust session management (e.g. [OWASP2013]).
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.
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.
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.
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.
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.
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.
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).
The FIDO UAF protocol specifies two different methods for replay-attack protection:
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.
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.
There is the potential that some attacker misuses a FIDO Authenticator for committing fraud, more specifically they would:
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.
FIDO supports Web Applications, Mobile Applications and Native PC Applications. Such applications are referred to as FIDO enabled applications.
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].
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.
This section is normative.
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].
See [UAFAuthnrCommands], section "TAG_UAFV1_KRD".
See [UAFAuthnrCommands], section "TAG_UAFV1_SIGNED_DATA".
See [FIDOGlossary].