Copyright © 2013-2016 FIDO Alliance All Rights Reserved.
FIDO authenticators may have many different form factors, characteristics and capabilities. This document defines a standard means to describe the relevant pieces of information about an authenticator in order to interoperate with it, or to make risk-based policy decisions about transactions involving a particular authenticator.
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.
DOM APIs are described using the ECMAScript [ECMA-262] bindings for WebIDL [WebIDL-ED].
Following [WebIDL-ED], dictionary members are optional unless they are explicitly marked as required.
WebIDL dictionary members MUST NOT have a value of null.
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.
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.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].
This section is non-normative.
The FIDO family of protocols enable simpler and more secure online authentication utilizing a wide variety of different devices in a competitive marketplace. Much of the complexity behind this variety is hidden from Relying Party applications, but in order to accomplish the goals of FIDO, Relying Parties must have some means of discovering and verifying various characteristics of authenticators. Relying Parties can learn a subset of verifiable information for authenticators certified by the FIDO Alliance with an Authenticator Metadata statement. The URL to access that Metadata statement is provided by the Metadata TOC file accessible through the Metadata Service [FIDOMetadataService].
For definitions of terms, please refer to the FIDO Glossary [FIDOGlossary].
This document describes the format of and information contained in Authenticator Metadata statements. For a definitive list of possible values for the various types of information, refer to the FIDO Registry of Predefined Values [FIDORegistry].
The description of the processes and methods by which authenticator metadata statements are distributed and the methods how these statements can be verified are described in the Metadata Service Specification [FIDOMetadataService].
The intended audience for this document includes:
Authenticator metadata statements are used directly by the FIDO server at a relying party, but the information contained in the authoritative statement is used in several other places. How a server obtains these metadata statements is described in [FIDOMetadataService].
The workflow around an authenticator metadata statement is as follows:
This section is normative.
The CodeAccuracyDescriptor
describes the relevant accuracy/complexity aspects
of passcode user verification methods.
One example of such a method is the use of 4 digit PIN codes for mobile phone SIM card unlock.
We are using the numeral system base
(radix) and
minLen
, instead of the number of potential combinations
since there is sufficient evidence [iPhonePasscodes] [MoreTopWorstPasswords]
that users don't select their code evenly distributed at random. So software
might take into account the various probability distributions for different bases.
This essentially means that in practice, passcodes are not as secure as they could be if randomly chosen.
dictionary CodeAccuracyDescriptor {
required unsigned short base;
required unsigned short minLength;
unsigned short maxRetries;
unsigned short blockSlowdown;
};
CodeAccuracyDescriptor
Membersbase
of type required unsigned shortminLength
of type required unsigned shortmaxRetries
of type unsigned shortblockSlowdown
of type unsigned shortuserVerificationDetails
.
The BiometricAccuracyDescriptor
describes relevant accuracy/complexity aspects
in the case of a biometric user verification method.
The False Acceptance Rate (FAR) and False Rejection Rate (FRR) values typically are interdependent via the Receiver Operator Characteristic (ROC) curve.
The False Artefact Acceptance Rate (FAAR) value reflects the capability of detecting presentation attacks, such as the detection of rubber finger presentation.
The FAR, FRR, and FAAR values given here MUST reflect the actual configuration of the authenticators (as opposed to being theoretical best case values).
At least one of the values MUST be set. If the vendor doesn't want to specify such values, then
VerificationMethodDescriptor.baDesc
MUST be omitted.
Typical fingerprint sensor characteristics can be found in Google Android 6.0 Compatibility Definition and Apple iOS Security Guide.
dictionary BiometricAccuracyDescriptor {
double FAR;
double FRR;
double EER;
double FAAR;
unsigned short maxReferenceDataSets;
unsigned short maxRetries;
unsigned short blockSlowdown;
};
BiometricAccuracyDescriptor
MembersFAR
of type double0.002%
would be encoded as 0.00002
.
The resulting FAR when all reference data
sets are used is maxReferenceDataSets * FAR
.
The false acceptance rate is relevant for the security. Lower false acceptance rates mean better security.
Only the live captured subjects are covered by this value - not the presentation of artefacts.
FRR
of type double10%
would be encoded as 0.1
.
The false rejection rate is relevant for the convenience. Lower false acceptance rates mean better convenience.
EER
of type doubleFAAR
of type double0.1%
would be encoded as 0.001
.
The false artefact acceptance rate is relevant for the security of the system. Lower false artefact acceptance rates imply better security.
maxReferenceDataSets
of type unsigned shortmaxRetries
of type unsigned shortblockSlowdown
of type unsigned shortuserVerificationDetails
.
The PatternAccuracyDescriptor
describes relevant accuracy/complexity aspects
in the case that a pattern is used as the user verification method.
One example of such a pattern is the 3x3 dot matrix as used in
Android [AndroidUnlockPattern] screen unlock. The minComplexity
would be 1624 in that case, based on the user choosing a 4-digit PIN, the minimum allowed for this mechanism.
dictionary PatternAccuracyDescriptor {
required unsigned long minComplexity;
unsigned short maxRetries;
unsigned short blockSlowdown;
};
PatternAccuracyDescriptor
MembersminComplexity
of type required unsigned longmaxRetries
of type unsigned shortblockSlowdown
of type unsigned shortuserVerificationDetails
.
A descriptor for a specific base user verification method as implemented by the authenticator.
A base user verification method must be chosen from the list of those described in [FIDORegistry]
In reality, several of the methods described above might be combined. For example, a fingerprint based user verification can be combined with an alternative password.
The specification of the related AccuracyDescriptor is optional, but recommended.
dictionary VerificationMethodDescriptor {
required unsigned long userVerification;
CodeAccuracyDescriptor
caDesc;
BiometricAccuracyDescriptor
baDesc;
PatternAccuracyDescriptor
paDesc;
};
VerificationMethodDescriptor
MembersuserVerification
of type required unsigned longUSER_VERIFY
constant
(see [FIDORegistry]), not a bit flag combination.
This value MUST be non-zero.
caDesc
of type CodeAccuracyDescriptor
USER_VERIFY_PASSCODE
.baDesc
of type BiometricAccuracyDescriptor
USER_VERIFY_FINGERPRINT
, USER_VERIFY_VOICEPRINT
,
USER_VERIFY_FACEPRINT
, USER_VERIFY_EYEPRINT
, or USER_VERIFY_HANDPRINT
.paDesc
of type PatternAccuracyDescriptor
USER_VERIFY_PATTERN
.typedef VerificationMethodDescriptor
[] VerificationMethodANDCombinations;
VerificationMethodANDCombinations
MUST be non-empty. It is a list containing
the base user verification methods which must be passed as part
of a successful user verification.
This list will contain only a single entry if using a single user verification method is sufficient.
If this list contains multiple entries, then all of the listed user verification methods MUST be passed as part of the user verification process.
The rgbPaletteEntry
is an RGB three-sample tuple palette entry
dictionary rgbPaletteEntry {
required unsigned short r;
required unsigned short g;
required unsigned short b;
};
rgbPaletteEntry
Membersr
of type required unsigned shortg
of type required unsigned shortb
of type required unsigned shortThe DisplayPNGCharacteristicsDescriptor describes a PNG image characteristics as defined in the PNG [PNG] spec for IHDR (image header) and PLTE (palette table)
dictionary DisplayPNGCharacteristicsDescriptor {
required unsigned long width;
required unsigned long height;
required octet bitDepth;
required octet colorType;
required octet compression;
required octet filter;
required octet interlace;
rgbPaletteEntry
[] plte;
};
DisplayPNGCharacteristicsDescriptor
Memberswidth
of type required unsigned longheight
of type required unsigned longbitDepth
of type required octetcolorType
of type required octetcompression
of type required octetfilter
of type required octetinterlace
of type required octetplte
of type array of rgbPaletteEntry
In the case of ECDAA attestation, the ECDAA-Issuer's trust anchor MUST be specified in this field.
dictionary EcdaaTrustAnchor {
required DOMString X;
required DOMString Y;
required DOMString c;
required DOMString sx;
required DOMString sy;
required DOMString G1Curve;
};
EcdaaTrustAnchor
MembersX
of type required DOMStringY
of type required DOMStringc
of type required DOMStringsx
of type required DOMStringsy
of type required DOMStringG1Curve
of type required DOMStringWhenever a party uses this trust anchor for the first time, it must first verify that it was correctly generated by verifying . See [FIDOEcdaaAlgorithm] for details.
dictionary ExtensionDescriptor {
required DOMString id;
DOMString data;
required boolean fail_if_unknown;
};
ExtensionDescriptor
Membersid
of type required DOMStringIdentifies the extension.
data
of type DOMStringThis field MAY be missing or it MAY be empty.
fail_if_unknown
of type required booleanfalse
) or must lead to an
error (true
) when the extension is to be processed by the FIDO Server, FIDO Client, ASM, or FIDO Authenticator.
false
indicates that unknown extensions MUST be ignoredtrue
indicates that unknown extensions MUST result in an error.This section is normative.
dictionary MetadataStatement {
AAID aaid;
AAGUID aaguid;
DOMString[] attestationCertificateKeyIdentifiers;
required DOMString description;
required unsigned short authenticatorVersion;
DOMString protocolFamily;
required Version[] upv;
required DOMString assertionScheme;
required unsigned short authenticationAlgorithm;
required unsigned short publicKeyAlgAndEncoding;
required unsigned short[] attestationTypes;
required VerificationMethodANDCombinations[] userVerificationDetails;
required unsigned short keyProtection;
boolean isKeyRestricted;
boolean isFreshUserVerificationRequired;
required unsigned short matcherProtection;
required unsigned long attachmentHint;
required boolean isSecondFactorOnly;
required unsigned short tcDisplay;
DOMString tcDisplayContentType;
DisplayPNGCharacteristicsDescriptor
[] tcDisplayPNGCharacteristics;
required DOMString[] attestationRootCertificates;
EcdaaTrustAnchor
[] ecdaaTrustAnchors;
DOMString icon;
ExtensionDescriptor
supportedExtensions[];
};
MetadataStatement
Membersaaid
of type AAIDFIDO UAF Authenticators support AAID, but they don't support AAGUID.
aaguid
of type AAGUIDFIDO 2 Authenticators support AAGUID, but they don't support AAID.
attestationCertificateKeyIdentifiers
of type array of DOMStringaaid
nor aaguid
are set. Setting this field implies that
the attestation certificate(s) are dedicated to a single authenticator model.
All attestationCertificateKeyIdentifier values should be unique within the scope of the Metadata Service.
FIDO U2F Authenticators typically do not support AAID nor AAGUID, but they use attestation certificates dedicated to a single authenticator model.
description
of type required DOMStringThis description should help an administrator configuring authenticator policies. This description might deviate from the description returned by the ASM for that authenticator.
This description should contain the public authenticator trade name and the publicly known vendor name.
authenticatorVersion
of type required unsigned shortauthenticatorVersion
meeting the requirements
specified in this metadata statement.
Adding new StatusReport
entries with status UPDATE_AVAILABLE
to
the metadata TOC
object [FIDOMetadataService] MUST also change this
authenticatorVersion
if the update fixes severe security issues, e.g. the ones
reported by preceding StatusReport
entries with status code
USER_VERIFICATION_BYPASS
,
ATTESTATION_KEY_COMPROMISE
, USER_KEY_REMOTE_COMPROMISE
,
USER_KEY_PHYSICAL_COMPROMISE
, REVOKED
.
It is RECOMMENDED to assume increased risk if this version is higher
(newer) than the firmware version
present in an authenticator. For example, if a StatusReport
entry with status
USER_VERIFICATION_BYPASS
or USER_KEY_REMOTE_COMPROMISE
precedes the
UPDATE_AVAILABLE
entry, than any firmware version lower (older) than the one
specified in the metadata statement is assumed to be vulnerable.
protocolFamily
of type DOMStringupv
of type array of required VersionVersion
structure.
assertionScheme
of type required DOMStringauthenticationAlgorithm
of type required unsigned shortALG_
constants defined in the
FIDO Registry of Predefined Values [FIDORegistry].
This value MUST be non-zero.
publicKeyAlgAndEncoding
of type required unsigned shortALG_KEY
constants defined in the
FIDO Registry of Predefined Values [FIDORegistry]. Because this information
is not present in APIs related to authenticator discovery or policy, a
FIDO server MUST be prepared to accept and process any and all key representations
defined for any public key algorithm it supports.
This value MUST be non-zero.
attestationTypes
of type array of required unsigned shortTAG_ATTESTATION_BASIC_FULL
) See
Registry for more information [UAFRegistry].
userVerificationDetails
of type array of required VerificationMethodANDCombinationsAll effectively available alternative user verification methods MUST be properly specified here. A user verification method is considered effectively available if this method can be used to either:
or
keyProtection
of type required unsigned shortKEY_PROTECTION
constants in the FIDO Registry of Predefined
Values [FIDORegistry].
This value MUST be non-zero.
The keyProtection specified here denotes the effective security of the attestation key and Uauth private key and the effective trustworthiness of the attested attributes in the “sign assertion”. Effective security means that key extraction or injecting malicious attested attributes is only possible if the specified protection method is compromised. For example, if keyProtection=TEE is stated, it shall be impossible to extract the attestation key or the Uauth private key or to inject any malicious attested attributes without breaking the TEE.
isKeyRestricted
of type booleanThis entry is set to true
, if the Uauth private key is restricted by the authenticator to only sign
valid FIDO signature assertions.
This entry is set to false
, if the authenticator doesn't restrict the Uauth key to only sign
valid FIDO signature assertions. In this case, the calling application could potentially get any hash
value signed by the authenticator.
If this field is missing, the assumed value is isKeyRestricted=true
Note that only in the case of isKeyRestricted=true
, the FIDO server can trust
a signature counter or transaction text to have been correctly processed/controlled by the authenticator.
isFreshUserVerificationRequired
of type booleanThis entry is set to true
, if Uauth key usage always requires a fresh user verification.
If this field is missing, the assumed value is isFreshUserVerificationRequired=true
.
This entry is set to false
, if the Uauth key can be used without
requiring a fresh user verification, e.g. without any additional user interaction,
if the user was verified a (potentially configurable) caching time ago.
In the case of isFreshUserVerificationRequired=false
,
the FIDO server MUST verify the registration response and/or authentication response and verify that the
(maximum) caching time (sometimes also called "authTimeout") is acceptable.
This entry solely refers to the user verification. In the case of transaction confirmation, the authenticator MUST always ask the user to authorize the specific transaction.
Note that in the case of isFreshUserVerificationRequired=false
, the calling App could trigger
use of the key without user involvement. In this case it is the responsibility of the App to ask for user consent.
matcherProtection
of type required unsigned shortMATCHER_PROTECTION
constants in the FIDO Registry of Predefined
Values [FIDORegistry].
This value MUST be non-zero.
If multiple matchers are implemented, then this value must reflect the weakest implementation of all matchers.
The matcherProtection specified here denotes the effective security of the FIDO authenticator’s user verification. This means that a false positive user verification implies breach of the stated method. For example, if matcherProtection=TEE is stated, it shall be impossible to trigger use of the Uauth private key when bypassing the user verification without breaking the TEE.
attachmentHint
of type required unsigned longATTACHMENT_HINT
constants in the FIDO Registry of Predefined
Values [FIDORegistry].
The connection state and topology of an
authenticator may be transient and cannot be relied on as
authoritative by a relying party, but the metadata field should
have all the bit flags set for the topologies possible for the
authenticator. For example, an authenticator instantiated as a
single-purpose hardware token that can communicate over
bluetooth should set ATTACHMENT_HINT_EXTERNAL
but not
ATTACHMENT_HINT_INTERNAL
.
isSecondFactorOnly
of type required booleantcDisplay
of type required unsigned shortTRANSACTION_CONFIRMATION_DISPLAY
constants in the FIDO Registry of Predefined
Values [FIDORegistry].
This value MUST be 0, if transaction confirmation is not supported by the authenticator.
The tcDisplay specified here denotes the effective security of the authenticator’s transaction confirmation display. This means that only a breach of the stated method allows an attacker to inject transaction text to be included in the signature assertion which hasn't been displayed and confirmed by the user.
tcDisplayContentType
of type DOMStringtext/plain
or image/png
.
This value MUST be present if transaction confirmation is supported,
i.e. tcDisplay
is non-zero.
tcDisplayPNGCharacteristics
of type array of DisplayPNGCharacteristicsDescriptor
This list MUST be present if PNG-image based transaction confirmation is supported,
i.e. tcDisplay
is non-zero and tcDisplayContentType
is image/png
.
attestationRootCertificates
of type array of required DOMStringEach array element is a base64-encoded (section 4 of [RFC4648]), DER-encoded [ITU-X690-2008] PKIX certificate value. Each element MUST be dedicated for authenticator attestation.
A certificate listed here is a trust root. It might be the actual certificate presented by the authenticator, or it might be an issuing authority certificate from the vendor that the actual certificate in the authenticator chains to.
In the case of "uaf" protocol family, the attestation certificate itself and the ordered certificate chain are included in the registration assertion (see [UAFAuthnrCommands]).
Either
or
MUST be specified.
In the case (1), the root certificate might cover multiple
authenticator models. In this case, it must be possible
to uniquely derive the authenticator model from the Attestation Certificate.
When using AAID or AAGUID, this can be achieved by either specifying the AAID or AAGUID
in the attestation certificate using the extension id-fido-gen-ce-aaid { 1 3 6 1 4 1 45724 1 1 1 } or
id-fido-gen-ce-aaguid { 1 3 6 1 4 1 45724 1 1 4 } or
- when neither AAID nor AAGUID are defined - by using the attestationCertificateKeyIdentifier
method.
In the case (2) this is not required as the root certificate only covers a single authenticator model.
When supporting surrogate basic attestation only (see [UAFProtocol], section "Surrogate Basic Attestation"), no attestation root certificate is required/used. So this array MUST be empty in that case.
ecdaaTrustAnchors
of type array of EcdaaTrustAnchor
attestationRootCertificates
have no relevance for ECDAA attestation.
Each ecdaaTrustAnchor MUST be dedicated to a single authenticator model (e.g as identified by its AAID/AAGUID).
icon
of type DOMStringdata:
url [RFC2397] encoded PNG [PNG] icon for the Authenticator.
supportedExtensions[]
of type ExtensionDescriptor
This section is non-normative.
A FIDO Authenticator Metadata Statement is a document containing a JSON encoded dictionary MetadataStatement.
Example of the metadata statement for an UAF authenticator with:
ALG_SIGN_SECP256R1_ECDSA_SHA256_RAW
authentication algorithm.ALG_KEY_ECC_X962_RAW
public key format (0x100=256 decimal).TAG_ATTESTATION_BASIC_FULL
method (0x3E07=15879 decimal).{ "aaid": "1234#5678", "description": "FIDO Alliance Sample UAF Authenticator", "authenticatorVersion": 2, "upv": [{ "major": 1, "minor": 0 }, { "major": 1, "minor": 1 }], "assertionScheme": "UAFV1TLV", "authenticationAlgorithm": 1, "publicKeyAlgAndEncoding": 256, "attestationTypes": [15879], "userVerificationDetails": [ [ { "userVerification": 2, "baDesc": { "FAR": 0.00002, "maxRetries": 5, "blockSlowdown": 30, "maxReferenceDataSets": 5 } } ] ], "keyProtection": 6, "isKeyRestricted": true, "matcherProtection": 2, "attachmentHint": 1, "isSecondFactorOnly": "false", "tcDisplay": 5, "tcDisplayContentType": "image/png", "tcDisplayPNGCharacteristics": [{"width": 320, "height": 480, "bitDepth": 16, "colorType": 2, "compression": 0, "filter": 0, "interlace": 0}], "attestationRootCertificates": [ "MIICPTCCAeOgAwIBAgIJAOuexvU3Oy2wMAoGCCqGSM49BAMCMHsxIDAeBgNVBAMM F1NhbXBsZSBBdHRlc3RhdGlvbiBSb290MRYwFAYDVQQKDA1GSURPIEFsbGlhbmNl MREwDwYDVQQLDAhVQUYgVFdHLDESMBAGA1UEBwwJUGFsbyBBbHRvMQswCQYDVQQI DAJDQTELMAkGA1UEBhMCVVMwHhcNMTQwNjE4MTMzMzMyWhcNNDExMTAzMTMzMzMy WjB7MSAwHgYDVQQDDBdTYW1wbGUgQXR0ZXN0YXRpb24gUm9vdDEWMBQGA1UECgwN RklETyBBbGxpYW5jZTERMA8GA1UECwwIVUFGIFRXRywxEjAQBgNVBAcMCVBhbG8g QWx0bzELMAkGA1UECAwCQ0ExCzAJBgNVBAYTAlVTMFkwEwYHKoZIzj0CAQYIKoZI zj0DAQcDQgAEH8hv2D0HXa59/BmpQ7RZehL/FMGzFd1QBg9vAUpOZ3ajnuQ94PR7 aMzH33nUSBr8fHYDrqOBb58pxGqHJRyX/6NQME4wHQYDVR0OBBYEFPoHA3CLhxFb C0It7zE4w8hk5EJ/MB8GA1UdIwQYMBaAFPoHA3CLhxFbC0It7zE4w8hk5EJ/MAwG A1UdEwQFMAMBAf8wCgYIKoZIzj0EAwIDSAAwRQIhAJ06QSXt9ihIbEKYKIjsPkri VdLIgtfsbDSu7ErJfzr4AiBqoYCZf0+zI55aQeAHjIzA9Xm63rruAxBZ9ps9z2XN lQ=="], "icon": "data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAE8AAAAvCAYAAACiwJfcAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAahSURBVGhD7Zr5bxRlGMf9KzTB8AM/YEhE2W7p QZcWKKBclSpHATlELARE7kNECCA3FkWK0CKKSCFIsKBcgVCDWGNESdAYidwgggJBiRiMhFc/4wy8 884zu9NdlnGTfZJP2n3nO++88933fveBBx+PqCzJkTUvBbLmpUDWvBTImpcCSZvXLCdX9R05Sk19 bb5atf599fG+/erA541q47aP1LLVa9SIyVNUi8Ii8d5kGTsi30NFv7ai9n7QZPMwbdys2erU2XMq Udy8+ZcaNmGimE8yXN3RUd3a18nF0fUlovZ+0CTzWpd2Vj+eOm1bEyy6Dx4i5pUMGWveo506q227 dtuWBIuffr6oWpV0FPNLhow1751Nm21LvPH3rVtWjfz66Lfql8tX7FRl9YFSXsmSseb9ceOGbYk7 MNUcGPg8ZsbMe9rfQUaaV/JMX9sqdzDCSvp0kZHmTZg9x7bLHcMnThb16eJ+mVfQq8yaUZQNG64i XZ+0/kq6uOZFO0QtatdWKfXnRQ99Bj91R5OIFnk54jN0mkUiqlO3XDW+Ml+98mKB6tW7rWpZcPc+ 0zg4tLrYlUc86E6eGDjIMubVpcusearfgIYGRk6brhZVr/JcHzooL7550jedLExopWcApi2ZUqhu 7JLvrVsQU81zkzOPeemMRYvVuQsX7PbiDQY5JvZonftK+1VY8H9utx530h0ob+jmRYqj6ouaYvEe nW/WlYjp8cwbMm682tPwqW1R4tj/2SH13IRJYl4moZvXpiSqDr7dXtQHxa/PK3/+BWsK1dTgHu6V 8tQJ3bwFkwpFrUOQ50s1r3levm8zZcq17+BBaw7K8lEK5qzkYeark9A8p7P3GzDK+nd3DQow+6UC 8SVN82iuv38im7NtaXtV1CVq6Rgw4pksmbdi3bu2De7YfaBBxcqfvqPrUjFQNTQ22lfdUVVT68rT JKF5DnSmUjgdqg4mSS9pmsfDJR3G6ToH0iW9aV7LWLHYXKllTDt0LTAtkYIaamp1QjVv++uyGUxV dJ0DNVXSm+b1qRxpl84ddfX1Lp1O/d69tsod0vs5hGre9xu8o+fpLR1cGhNTD6Z57C9KMWXefJdO Z94bb9oqd1ROnS7qITTzHimMqivbO3g0DdVyk3WQBhBztK35YKNdOnc8O3acS6fDZFgKaXLsEJp5 rdrliBqp89cJcs/m7Tvs0rkjGfN4b0kPoZn3UJuIOrnZ22yP1fmvUx+O5gSqebV1m+zSuYNVhq7T WbDiLVvljplLlop6CLXP+2qtvGLIL/1vimISdMBgzSoFZyu6Tqd+jzxgsPaV9BCqee/NjYk6v6lK 9cwiUc/STtf1HDpM3b592y7h3Thx5ozK69HLpYWuAwaqS5cv26q7ceb8efVYaReP3iFU8zj1knSw ZXHMmnCjY0Ogalo7UQfSCM3qQQr2H/XFP7ssXx45Yl91ByeCep4moZoH+1fG3xD4tT7x8kwyj8nw b9ev26V0B6d+7H4zKvudAH537FjqyzOHdJnHEuzmXq/WjxObvNMbv7nhywsX2aVsWtC8+48aLeap E7p5wKZi0A2AQRV5nvR4E+uJc+b61kApqInxBgmd/4V5QP/mt18HDC7sRHftmeu5lmhV0rn/ALX2 32bqd4BFnDx7Vi1cWS2uff0IbB47qexxmUj9QutYjupd3tYD6abWBBMrh+apNbOKrNF1+ugCa4ri XGfwMPPtViavhU3YMOAAnuUb/R07L0yOSeOadE88ApsXFGff30ynhlJgM51CU6vN9EzgnpvHBFUy iVraePiwJ53DF5ZTZnomENg85kNUd2oJi2Wpr4OmmkfN4x4zHfiVFc8Dv8NzuhNqOidilGvA6DGu eZwO78AAQn6ciEk6+rw5VcvjvqNDYPOoIUwaKShrxAuXLlkH4aYuGfMYDc10WF5Ta31hPJOfcUhr U/JlINi6c6elRYdBpo6++Yfjx61lGNfRm4MD5rJ1j3FoGHnjDSBNarYUgMLyMszKpb7tXpoHfPs8 h3Wp1LzNfNk54XxC1wDGUmYzXYefh6z/cKtVm4EBxa9VQGDzYr3LrUMRjHEKkk7zaFKYQA2hGQU1 z+85NFWpXDrkz3vx10GqxQ6BzeNboBk5n8k4nebRh+k1hWfxTF0D1EyWUs5nv+dgQqKaxzuCdE0i sHl02NQ8ah0mXr12La3m0f9wik9+wLNTMY/86MPo8yi31OfxmT6PWoqG9+DZukYna56mSZt5WWSy 5qVA1rwUyJqXAlnzkiai/gHSD7RkTyihogAAAABJRU5ErkJggg==" }
Example of an User Verification Methods entry for an authenticator with:
[ [ { "userVerification": 2, "baDesc": { "FAR": 0.00002, "maxReferenceDataSets": 5, "maxRetries": 5, "blockSlowdown": 0} }], [ { "userVerification": 4, "caDesc": { "base": 10, "minLength": 4 } } ] ]
Example of the metadata statement for an U2F authenticator with:
ALG_SIGN_SECP256R1_ECDSA_SHA256_RAW
authentication algorithm.ALG_KEY_ECC_X962_RAW
public key format (0x100=256 decimal).TAG_ATTESTATION_BASIC_FULL
method (0x3E07=15879 decimal).{ "description": "FIDO Alliance Sample U2F Authenticator", "attestationCertificateKeyIdentifiers": ["7c0903708b87115b0b422def3138c3c864e44573"], "protocolFamily": "u2f", "authenticatorVersion": 2, "upv": [{ "major": 1, "minor": 0 }], "assertionScheme": "U2FV1BIN", "authenticationAlgorithm": 1, "publicKeyAlgAndEncoding": 256, "attestationTypes": [15879], "userVerificationDetails": [ [ { "userVerification": 1} ] ], "keyProtection": 10, "matcherProtection": 4, "attachmentHint": 2, "isSecondFactorOnly": "true", "tcDisplay": 0, "attestationRootCertificates": [ "MIICPTCCAeOgAwIBAgIJAOuexvU3Oy2wMAoGCCqGSM49BAMCMHsxIDAeBgNVBAMM F1NhbXBsZSBBdHRlc3RhdGlvbiBSb290MRYwFAYDVQQKDA1GSURPIEFsbGlhbmNl MREwDwYDVQQLDAhVQUYgVFdHLDESMBAGA1UEBwwJUGFsbyBBbHRvMQswCQYDVQQI DAJDQTELMAkGA1UEBhMCVVMwHhcNMTQwNjE4MTMzMzMyWhcNNDExMTAzMTMzMzMy WjB7MSAwHgYDVQQDDBdTYW1wbGUgQXR0ZXN0YXRpb24gUm9vdDEWMBQGA1UECgwN RklETyBBbGxpYW5jZTERMA8GA1UECwwIVUFGIFRXRywxEjAQBgNVBAcMCVBhbG8g QWx0bzELMAkGA1UECAwCQ0ExCzAJBgNVBAYTAlVTMFkwEwYHKoZIzj0CAQYIKoZI zj0DAQcDQgAEH8hv2D0HXa59/BmpQ7RZehL/FMGzFd1QBg9vAUpOZ3ajnuQ94PR7 aMzH33nUSBr8fHYDrqOBb58pxGqHJRyX/6NQME4wHQYDVR0OBBYEFPoHA3CLhxFb C0It7zE4w8hk5EJ/MB8GA1UdIwQYMBaAFPoHA3CLhxFbC0It7zE4w8hk5EJ/MAwG A1UdEwQFMAMBAf8wCgYIKoZIzj0EAwIDSAAwRQIhAJ06QSXt9ihIbEKYKIjsPkri VdLIgtfsbDSu7ErJfzr4AiBqoYCZf0+zI55aQeAHjIzA9Xm63rruAxBZ9ps9z2XN lQ=="],
This section is non-normative.
Metadata statements are intended to be stable once they have been published. When authenticators
are updated in the field, such updates are expected to improve the authenticator security
(for example, improve FRR or FAR).
The authenticatorVersion
must be updated if firmware updates fixing severe security
issues (e.g. as reported previously) are available.
The metadata statement is assumed to relate to all authenticators having the same AAID.
The FIDO Server is recommended to assume increased risk if the authenticatorVersion
specified in the metadata statement is newer (higher) than the one present in the authenticator.
Significant changes in authenticator functionality are not anticipated in firmware updates. For example, if an authenticator vendor wants to modify a PIN-based authenticator to use "Speaker Recognition" as a user verification method, the vendor MUST assign a new AAID to this authenticator.
A single authenticator implementation could report itself as two "virtual"
authenticators using different AAIDs. Such implementations MUST properly (i.e. according to
the security characteristics claimed in the metadata) protect UAuth
keys
and other sensitive data from the other "virtual" authenticator
- just as a normal authenticator would do.
Authentication keys (UAuth.pub
) registered for one AAID cannot
be used by authenticators reporting a different AAID - even when running on the same hardware
(see section "Authentication Response Processing Rules for FIDO Server" in [UAFProtocol]).