The English version of this specification is the only normative version. Non-normative translations may also be available.
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 Proposed Standard. If you wish to make comments regarding this document, please Contact Us. All comments are welcome.
Implementation of certain elements of this Specification may require licenses under third party intellectual property rights, including without limitation, patent rights. The FIDO Alliance, Inc. and its Members and any other contributors to the Specification are not, and shall not be held, responsible in any manner for identifying or failing to identify any or all such third party intellectual property rights.
THIS FIDO ALLIANCE SPECIFICATION IS PROVIDED “AS IS” AND WITHOUT ANY WARRANTY OF ANY KIND, INCLUDING, WITHOUT LIMITATION, ANY EXPRESS OR IMPLIED WARRANTY OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document has been reviewed by FIDO Aliance Members and is endorsed as a Proposed Standard. It is a stable document and may be used as reference material or cited from another document. FIDO Alliance's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment.
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;
};