Copyright © 2013-2018 FIDO Alliance All Rights Reserved.
The FIDO Authenticator Metadata Specification defines so-called "Authenticator Metadata" statements. The metadata statements contain the "Trust Anchor" required to validate the attestation object, and they also describe several other important characteristics of the authenticator.
The metadata service described in this document defines a baseline method for relying parties to access the latest metadata statements.
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 Review 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 is a Review Draft Specification and is not intended to be a basis for any implementations as the Specification may change. Permission is hereby granted to use the Specification solely for the purpose of reviewing 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(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.
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.
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.
[FIDOMetadataStatement] defines authenticator metadata statements.
These metadata statements
contain the trust anchor required to verify the attestation object
(more specifically the KeyRegistrationData object), and they also
describe several other important characteristics of the
authenticator, including supported authentication and registration
assertion schemes, and key protection flags.
These characteristics can be used when defining policies about which authenticators are acceptable for registration or authentication.
The metadata service described in this document defines a baseline method for relying parties to access the latest metadata statements.
This document describes the FIDO Metadata Service architecture in detail and it defines the structure and interface to access this service. It also defines the flow of the metadata related messages and presents the rationale behind the design choices.
The metadata "table-of-contents" (TOC) file contains a list of metadata statements related to the authenticators known to the FIDO Alliance (FIDO Authenticators).
The FIDO Server downloads the metadata TOC file from a well-known FIDO URL and caches it locally.
The FIDO Server verifies the integrity and authenticity of this metadata TOC file using the digital signature. It then iterates through the individual entries and loads the metadata statements related to authenticator AAIDs relevant to the relying party.
Individual metadata statements will be downloaded from the URL specified in the entry of the metadata TOC file, and may be cached by the FIDO Server as required.
The integrity of the metadata statements will be verified by the FIDO Server using the hash value included in the related entry of the metadata TOC file.
The single arrow indicates the direction of the network connection, the double arrow indicates the direction of the data flow.
The metadata TOC file is accessible at a well-known URL published by the FIDO Alliance.
The relying party decides how frequently the metadata service is accessed to check for metadata TOC updates.
This section is normative.
The relying party can decide whether it wants to use the metadata service and whether or not it wants to accept certain authenticators for registration or authentication.
The relying party could also obtain metadata directly from authenticator vendors or other trusted sources.
The metadata service makes the metadata TOC object (see Metadata TOC) accessible to FIDO Servers.
This object is a "table-of-contents" for metadata, as it includes the AAID, the download URL and the hash value of the individual metadata statements. The TOC object contains one signature.
Represents the MetadataTOCPayloadEntry
dictionary MetadataTOCPayloadEntry {
AAID aaid;
AAGUID aaguid;
DOMString[] attestationCertificateKeyIdentifiers;
DOMString hash;
DOMString url;
BiometricStatusReport[] biometricStatusReports;
required StatusReport[] statusReports;
required DOMString timeOfLastStatusChange;
DOMString rogueListURL;
DOMString rogueListHash;
};MetadataTOCPayloadEntry 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.
FIDO U2F authenticators do not support AAID nor AAGUID, but they use attestation certificates dedicated to a single authenticator model.
hash of type DOMStringbase64url(string[1..512])
The hash value computed over the base64url encoding of the UTF-8
representation of the JSON encoded metadata statement
available at url and as defined in [FIDOMetadataStatement].
The hash algorithm related to the signature
algorithm specified in the JWTHeader (see Metadata TOC)
MUST be used.
If this field is missing, the metadata statement has not been published.
This method of base64url encoding the UTF-8 representation is also used by JWT [JWT] to avoid encoding ambiguities.
url of type DOMStringIf this field is missing, the metadata statement has not been published.
encodedMetadataStatement = base64url(utf8(JSONMetadataStatement))
This method of the base64url encoding the UTF-8 representation is also used by JWT [JWT] to avoid encoding ambiguities.
biometricStatusReports of type array of BiometricStatusReportstatusReports of type array of required StatusReporttimeOfLastStatusChange of type required DOMStringrogueListURL of type DOMStringrogueListHash of type DOMStringbase64url(string[1..512])
The hash value computed over the Base64url encoding of the UTF-8
representation of the JSON encoded rogueList
available at rogueListURL (with type rogueListEntry[]).
The hash algorithm related to the signature
algorithm specified in the JWTHeader (see Metadata TOC)
MUST be used.
This hash value MUST be present and non-empty whenever rogueListURL is present.
This method of base64url-encoding the UTF-8 representation is also used by JWT [JWT] to avoid encoding ambiguities.
{ "no": 1234, "nextUpdate": "2014-03-31",
"entries": [
{ "aaid": "1234#5678",
"hash": "kNqNpt4jJIq7NNoNSGH0swp5PhmKjVuqf5jyYNtxrNQ",
"url": "https://fidoalliance.org/metadata/1234%x23abcd",
"rogueListHash": "tQec9A_X7RdMZFzATfHnK38SKVkFhdFt9i3SC5VBxrU",
"rogueListURL": "https://fidoalliance.org/metadata/1234%x23abcd.rl",
"statusReports": [
{ status: "FIDO_CERTIFIED", effectiveDate: "2014-01-04"}
],
"timeOfLastStatusChange": "2014-01-04"
},
{ "attestationCertificateKeyIdentifiers": ["7c0903708b87115b0b422def3138c3c864e44573"],
"hash": "eF0W32QP17UO0XTLVkXMDx5yt_Gc8ilZBS3SC5VBxk0",
"url": "https://authnr-vendor-a.com/metadata/9876%x234321",
"statusReports": [
{ status: "FIDO_CERTIFIED", effectiveDate: "2014-01-07"},
{ status: "UPDATE_AVAILABLE", effectiveDate: "2014-02-19",
url: "https://example.com/update1234" }
],
"timeOfLastStatusChange": "2014-02-19"
}
]
}The character # is a reserved character and not allowed in URLs [RFC3986].
As a consequence it has been replaced by its hex value %x23.
The authenticator vendors can decide to let the metadata service publish its metadata statements or to publish metadata statements themselves. Authenticator vendors can restrict access to the metadata statements they publish themselves.
Contains the current BiometricStatusReport of one of the authenticator's biometric component.
dictionary BiometricStatusReport {
required unsigned short certLevel;
required unsigned long modality;
DOMString effectiveDate;
DOMString certificationDescriptor;
DOMString certificateNumber;
DOMString certificationPolicyVersion;
DOMString certificationRequirementsVersion;
};BiometricStatusReport MemberscertLevel of type required unsigned shortmodality of type required unsigned longUSER_VERIFY constant indicating the modality of the biometric component
(see [FIDORegistry]), not a bit flag combination.
This value MUST be non-zero and this value MUST correspond to
one or more entries in field userVerificationDetails in the related
Metadata Statement [FIDOMetadataStatement].
For example use USER_VERIFY_FINGERPRINT for the fingerprint based biometric component.
In this case the related Metadata Statement must also claim fingerprint as one of the user verification methods.
effectiveDate of type DOMStringcertLevel achieved,
if applicable. If no date is given, the status is assumed to be effective while present.
certificationDescriptor of type DOMStringcertificateNumber of type DOMStringcertificationPolicyVersion of type DOMStringcertificationRequirementsVersion of type DOMStringContains an AuthenticatorStatus and additional data associated with it, if any.
New StatusReport entries will be added to report known issues present in firmware updates.
The latest StatusReport entry MUST reflect the "current" status.
For example, if the latest entry has status
USER_VERIFICATION_BYPASS, then it is recommended assuming an increased risk associated with
all authenticators of this AAID; if the latest entry has status UPDATE_AVAILABLE, then
the update is intended to address at least all previous
issues reported in this StatusReport dictionary.
dictionary StatusReport {
required AuthenticatorStatus status;
DOMString effectiveDate;
DOMString certificate;
DOMString url;
DOMString certificationDescriptor;
DOMString certificateNumber;
DOMString certificationPolicyVersion;
DOMString certificationRequirementsVersion;
};StatusReport Membersstatus of type required AuthenticatorStatuseffectiveDate of type DOMStringcertificate of type DOMStringAs an example, this could be an Attestation Root Certificate (see [FIDOMetadataStatement]) related to a set of compromised authenticators (ATTESTATION_KEY_COMPROMISE).
url of type DOMStringFor example a link to a web page describing an available firmware update in the case of status
UPDATE_AVAILABLE, or a link to a description of an identified issue in the case of
status USER_VERIFICATION_BYPASS.
certificationDescriptor of type DOMStringcertificateNumber of type DOMStringcertificationPolicyVersion of type DOMStringcertificationRequirementsVersion of type DOMStringThis enumeration describes the status of an authenticator model as identified by its AAID and potentially some additional information (such as a specific attestation key).
enum AuthenticatorStatus {
"NOT_FIDO_CERTIFIED",
"FIDO_CERTIFIED",
"USER_VERIFICATION_BYPASS",
"ATTESTATION_KEY_COMPROMISE",
"USER_KEY_REMOTE_COMPROMISE",
"USER_KEY_PHYSICAL_COMPROMISE",
"UPDATE_AVAILABLE",
"REVOKED",
"SELF_ASSERTION_SUBMITTED",
"FIDO_CERTIFIED_L1",
"FIDO_CERTIFIED_L1plus",
"FIDO_CERTIFIED_L2",
"FIDO_CERTIFIED_L2plus",
"FIDO_CERTIFIED_L3",
"FIDO_CERTIFIED_L3plus"
};| Enumeration description | |
|---|---|
NOT_FIDO_CERTIFIED | This authenticator is not FIDO certified. |
FIDO_CERTIFIED | This authenticator has passed FIDO functional certification. This certification scheme is phased out and will be replaced by FIDO_CERTIFIED_L1. |
USER_VERIFICATION_BYPASS | Indicates that malware is able to bypass the user verification. This means that the authenticator could be used without the user's consent and potentially even without the user's knowledge. |
ATTESTATION_KEY_COMPROMISE | Indicates that an attestation key for this authenticator is known to be compromised. Additional data should be supplied, including the key identifier and the date of compromise, if known. |
USER_KEY_REMOTE_COMPROMISE | This authenticator has identified weaknesses that allow registered keys to be compromised and should not be trusted. This would include both, e.g. weak entropy that causes predictable keys to be generated or side channels that allow keys or signatures to be forged, guessed or extracted. |
USER_KEY_PHYSICAL_COMPROMISE | This authenticator has known weaknesses in its key protection mechanism(s) that allow user keys to be extracted by an adversary in physical possession of the device. |
UPDATE_AVAILABLE | A software or firmware update is available for the device.
Additional data should be supplied including a URL where
users can obtain an update and
the date the update was published.
When this code is used, then the field
Note Relying parties might want to inform users about available firmware updates. |
REVOKED | The FIDO Alliance has determined that this authenticator should not be trusted for any reason, for example if it is known to be a fraudulent product or contain a deliberate backdoor. |
SELF_ASSERTION_SUBMITTED | The authenticator vendor has completed and submitted the self-certification
checklist to the FIDO Alliance.
If this completed checklist is publicly available, the URL will be
specified in StatusReport.url.
|
FIDO_CERTIFIED_L1 | The authenticator has passed FIDO Authenticator certification at level 1. This level is the more strict successor of FIDO_CERTIFIED. |
FIDO_CERTIFIED_L1plus | The authenticator has passed FIDO Authenticator certification at level 1+. This level is the more than level 1. |
FIDO_CERTIFIED_L2 | The authenticator has passed FIDO Authenticator certification at level 2. This level is more strict than level 1+. |
FIDO_CERTIFIED_L2plus | The authenticator has passed FIDO Authenticator certification at level 2+. This level is more strict than level 2. |
FIDO_CERTIFIED_L3 | The authenticator has passed FIDO Authenticator certification at level 3. This level is more strict than level 2+. |
FIDO_CERTIFIED_L3plus | The authenticator has passed FIDO Authenticator certification at level 3+. This level is more strict than level 3. |
More values might be added in the future. FIDO Servers MUST silently ignore all unknown AuthenticatorStatus values.
Contains a list of individual authenticators known to be rogue.
New RogueListEntry entries will be added to report new
individual authenticators known to be rogue.
Old RogueListEntry entries will be removed if
the individual authenticator is known to not be rogue any longer.
dictionary RogueListEntry {
required DOMString sk;
required DOMString date;
};RogueListEntry Memberssk of type required DOMStringIn order to revoke an individual authenticator, its secret key (sk) must be known.
date of type required DOMString[
{ "sk": "MO-oaqbeJSSayzXaDUhh9LMKeT4Zio1bqn6W8kDaUfM",
"date": "2016-06-07"},
{ "sk": "k96Npt4jJIq7NNoNSGH0swp5PhU6jVuyf5jyYNtxrNQ",
"date": "2016-06-09"},
]Represents the MetadataTOCPayload
dictionary MetadataTOCPayload {
DOMString legalHeader;
required Number no;
required DOMString nextUpdate;
required MetadataTOCPayloadEntry[] entries;
};MetadataTOCPayload MemberslegalHeader of type DOMStringno of type required Numberno value
exactly incremented by one.nextUpdate of type required DOMStringentries of type array of required MetadataTOCPayloadEntryThe metadata table of contents (TOC) is a JSON Web Token (see [JWT] and [JWS]).
It consists of three elements:
tbsPayload = EncodedJWTHeader | "." | EncodedMetadataTOCPayload
All three elements of the TOC are concatenated by a period ("."):
MetadataTOC = EncodedJWTHeader | "." | EncodedMetadataTOCPayload | "." | EncodedJWSSignature
The hash algorithm related to the signing algorithm specified in the JWT Header (e.g. SHA256 in the case of "ES256") MUST also be used to compute the hash of the metadata statements (see section Metadata TOC Payload Entry Dictionary).
This section is non-normative.
eyAiQUFJRCI6ICIxMjM0IzU2NzgiLA0KICAiQXR0ZXN0YXRpb25Sb290Q2VydGlmaWNhdGUiOiAi TUlJQ1BUQ0NBZU9nQXdJQkFnSUpBT3VleHZVM095MndNQW9HQ0NxR1NNNDlCQU1DTUhzeElEQWVC Z05WQkFNTQ0KRjFOaGJYQnNaU0JCZEhSbGMzUmhkR2x2YmlCU2IyOTBNUll3RkFZRFZRUUtEQTFH U1VSUElFRnNiR2xoYm1ObA0KTVJFd0R3WURWUVFMREFoVlFVWWdWRmRITERFU01CQUdBMVVFQnd3 SlVHRnNieUJCYkhSdk1Rc3dDUVlEVlFRSQ0KREFKRFFURUxNQWtHQTFVRUJoTUNWVk13SGhjTk1U UXdOakU0TVRNek16TXlXaGNOTkRFeE1UQXpNVE16TXpNeQ0KV2pCN01TQXdIZ1lEVlFRRERCZFRZ VzF3YkdVZ1FYUjBaWE4wWVhScGIyNGdVbTl2ZERFV01CUUdBMVVFQ2d3Tg0KUmtsRVR5QkJiR3hw WVc1alpURVJNQThHQTFVRUN3d0lWVUZHSUZSWFJ5d3hFakFRQmdOVkJBY01DVkJoYkc4Zw0KUVd4 MGJ6RUxNQWtHQTFVRUNBd0NRMEV4Q3pBSkJnTlZCQVlUQWxWVE1Ga3dFd1lIS29aSXpqMENBUVlJ S29aSQ0KemowREFRY0RRZ0FFSDhodjJEMEhYYTU5L0JtcFE3UlplaEwvRk1HekZkMVFCZzl2QVVw T1ozYWpudVE5NFBSNw0KYU16SDMzblVTQnI4ZkhZRHJxT0JiNThweEdxSEpSeVgvNk5RTUU0d0hR WURWUjBPQkJZRUZQb0hBM0NMaHhGYg0KQzBJdDd6RTR3OGhrNUVKL01COEdBMVVkSXdRWU1CYUFG UG9IQTNDTGh4RmJDMEl0N3pFNHc4aGs1RUovTUF3Rw0KQTFVZEV3UUZNQU1CQWY4d0NnWUlLb1pJ emowRUF3SURTQUF3UlFJaEFKMDZRU1h0OWloSWJFS1lLSWpzUGtyaQ0KVmRMSWd0ZnNiRFN1N0Vy SmZ6cjRBaUJxb1lDWmYwK3pJNTVhUWVBSGpJekE5WG02M3JydUF4Qlo5cHM5ejJYTg0KbFE9PSIs DQogICJEZXNjcmlwdGlvbiI6ICJGSURPIEFsbGlhbmNlIFNhbXBsZSBVQUYgQXV0aGVudGljYXRv ciIsDQogICJVc2VyVmVyaWZpY2F0aW9uTWV0aG9kcyI6IDIsDQogICJWYWxpZEF0dGFjaG1lbnRU eXBlcyI6IDEsDQogICJLZXlQcm90ZWN0aW9uIjogNiwNCiAgIk1hdGNoZXJQcm90ZWN0aW9uIjog MiwNCiAgIlNlY3VyZURpc3BsYXkiOiA0LA0KICAiU2VjdXJlRGlzcGxheUNvbnRlbnRUeXBlcyI6 IFsiaW1hZ2UvcG5nIl0sDQogICJTZWN1cmVEaXNwbGF5UE5HQ2hhcmFjdGVyaXN0aWNzIjogW1sw LDAsMSw2NCwwLDAsMSwyMjQsMTYsMiwwLDAsMF1dLA0KICAiaXNTZWNvbmRGYWN0b3JPbmx5Ijog ImZhbHNlIiwNCiAgIkljb24iOiAiZGF0YTppbWFnZS9wbmc7YmFzZTY0LGlWQk9SdzBLR2dvQUFB QU5TVWhFVWdBQUFFOEFBQUF2Q0FZQUFBQ2l3SmZjQUFBQUFYTlNSMElBcnM0YzZRQUFBQVJuUVUx QkFBQ3gNCmp3djhZUVVBQUFBSmNFaFpjd0FBRHNNQUFBN0RBY2R2cUdRQUFBYWhTVVJCVkdoRDda cjVieFJsR01mOUt6VEI4QU0vWUVoRTJXN3ANClFaY1dLS0JjbFNwSEFUbEVMQVJFN2tORUNDQTNG a1dLMENLS1NDRklzS0JjZ1ZDRFdHTkVTZEFZaWR3Z2dnSkJpUmlNaEZjLzR3eTgNCjg4NHp1OU5k bG5HVGZaSlAybjNuTysrODg5MzNmdmVCQngrUHFDekprVFV2QmJMbXBVRFd2QlRJbXBjQ1NadlhM Q2RYOVIwNVNrMTkNCmJiNWF0ZjU5OWZHKy9lckE1NDFxNDdhUDFMTFZhOVNJeVZOVWk4SWk4ZDVr R1RzaTMwTkZ2N2FpOW43UVpQTXdiZHlzMmVyVTJYTXENClVkeTgrWmNhTm1HaW1FOHlYTjNSVWQz YTE4bkYwZlVsb3ZaKzBDVHpXcGQyVmorZU9tMWJFeXk2RHg0aTVwVU1HV3ZlbzUwNnEyMjcNCmR0 dVdCSXVmZnI2b1dwVjBGUE5MaG93MTc1MU5tMjFMdlBIM3JWdFdqZno2NkxmcWw4dFg3RlJsOVlG U1hzbVNzZWI5Y2VPR2JZazcNCk1OVWNHUGc4WnNiTWU5cmZRVWFhVi9KTVg5c3FkekRDU3ZwMGta SG1UWmc5eDdiTEhjTW5UaGIxNmVKK21WZlFxOHlhVVpRTkc2NGkNClhaKzAva3E2dU9aRk8wUXRh dGRXS2ZYblJROTlCajkxUjVPSUZuazU0ak4wbWtVaXFsTzNYRFcrTWwrOThtS0I2dFc3cldwWmNQ YysNCjB6ZzR0THJZbFVjODZFNmVHRGpJTXViVnBjdXNlYXJmZ0lZR1JrNmJyaFpWci9KY0h6b29M NzU1MGplZExFeG9wV2NBcGkyWlVxaHUNCjdKTHZyVnNRVTgxemt6T1BlZW1NUll2VnVRc1g3UGJp RFFZNUp2Wm9uZnRLKzFWWThIOXV0eDUzMGgwb2Iram1SWXFqNm91YVl2RWUNCm5XL1dsWWpwOGN3 Yk1tNjgydFB3cVcxUjR0ai8yU0gxM0lSSllsNG1vWnZYcGlTcURyN2RYdFFIeGEvUEszLytCV3NL MWRUZ0h1NlYNCjh0UUozYndGa3dwRnJVT1E1MHMxcjNsZXZtOHpaY3ExNytCQmF3N0s4bEVLNXF6 a1llYXJrOUE4cDdQM0d6REsrbmQzRFFvdys2VUMNCjhTVk44Mml1djM4aW03TnRhWHRWMUNWcTZS Z3c0cGtzbWJkaTNidTJEZTdZZmFCQnhjcWZ2cVByVWpGUU5UUTIybGZkVVZWVDY4clQNCkpLRjVE blNtVWpnZHFnNG1TUzlwbXNmREpSM0c2VG9IMGlXOWFWN0xXTEhZWEtsbFREdDBMVEF0a1lJYWFt cDFRalZ2Kyt1eUdVeFYNCmRKMEROVlhTbStiMXFSeHBsODRkZGZYMUxwMU8vZDY5dHNvZDB2czVo R3JlOXh1OG8rZnBMUjFjR2hOVEQ2WjU3QzlLTVdYZWZKZE8NClo5NGJiOW9xZDFST25TN3FJVFR6 SGltTXFpdmJPM2cwRGRWeWszV1FCaEJ6dEszNVlLTmRPbmM4TzNhY1M2ZkRaRmdLYVhMc0VKcDUN CnJkcmxpQnFwODljSmNzL203VHZzMHJrakdmTjRiMGtQb1puM1VKdUlPcm5aMjJ5UDFmbXZVeCtP NWdTcWViVjFtK3pTdVlOVmhxN1QNCldiRGlMVnZsanBsTGxvcDZDTFhQKzJxdHZHTElMLzF2aW1J U2RNQmd6U29GWnl1NlRxZCtqenhnc1BhVjlCQ3FlZS9OallrNnY2bEsNCjljd2lVYy9TVHRmMUhE cE0zYjU5Mnk3aDNUaHg1b3pLNjlITHBZV3VBd2FxUzVjdjI2cTdjZWI4ZWZWWWFSZVAzaUZVOHpq MWtuU3cNClpYSE1tbkNqWTBPZ2FsbzdVUWZTQ00zcVFRcjJIL1hGUDdzc1h4NDVZbDkxQnllQ2Vw NG1vWm9IKzFmRzN4RDR0VDd4OGt3eWo4bncNCmI5ZXYyNlYwQjZkKzdINHpLdnVkQUg1MzdGanF5 ek9IZEpuSEV1em1YcS9XanhPYnZOTWJ2N25oeXdzWDJhVnNXdEM4KzQ4YUxlYXANCkU3cDV3S1pp MEEyQVFSVjVudlI0RSt1SmMrYjYxa0FwcUlueEJnbWQvNFY1UVAvbXQxOEhEQzdzUkhmdG1ldTVs bWhWMHJuL0FMWDINCjMyYnFkNEJGbkR4N1ZpMWNXUzJ1ZmYwSWJCNDdxZXh4bVVqOVF1dFlqdXBk M3RZRDZhYldCQk1yaCthcE5iT0tyTkYxK3VnQ2E0cmkNClhHZndNUFB0VmlhdmhVM1lNT0FBbnVV Yi9SMDdMMHlPU2VPYWRFODhBcHNYRkdmZjMweW5obEpnTTUxQ1U2dk45RXpnbnB2SEJGVXkNCmlW cmFlUGl3SjUzREY1WlRabm9tRU5nODVrTlVkMm9KaTJXcHI0T21ta2ZONHg0ekhmaVZGYzhEdjhO enVoTnFPaWRpbEd2QTZER3UNCmVad083OEFBUW42Y2lFazYrcnc1VmN2anZxTkRZUE9vSVV3YUtT aHJ4QXVYTGxrSDRhWXVHZk1ZRGMxMFdGNVRhMzFoUEpPZmNVaHINClUvSmxJTmk2YzZlbFJZZEJw bzYrK1lmang2MWxHTmZSbTRNRDVySjFqM0ZvR0huakRTQk5hcllVZ01MeU1zektwYjd0WHBvSGZQ czgNCmgzV3AxTHpOZk5rNTRYeEMxd0RHVW1ZelhZZWZoNnovY0t0Vm00RUJ4YTlWUUdEellyM0xy VU1SakhFS2trN3phRktZUUEyaEdRVTENCnorODVORldwWERya3ozdngxMEdxeFE2QnplTmJvQms1 bjhrNG5lYlJoK2sxaFdmeFRGMEQxRXlXVXM1bnYrZGdRcUtheHp1Q2RFMGkNCnNIbDAyTlE4YWgw bVhyMTJMYTNtMGY5d2lrOSt3TE5UTVkvODZNUG84eWkzMU9meG1UNlBXb3FHOStEWnVrWW5hNTZt U1p0NVdXU3kNCjVxVkExcndVeUpxWEFsbnpraWFpL2dIU0Q3UmtUeWlob2dBQUFBQkpSVTVFcmtK Z2dnPT0iLA0KICAiQXNzZXJ0aW9uU2NoZW1lIjogIlVBRlYxVExWIiwNCiAgIkF1dGhlbnRpY2F0 aW9uQWxnb3JpdGhtIjogMSwNCiAgIkF0dGVzdGF0aW9uVHlwZXMiOiBbMTYzOTFdLA0KICAiVVBW IjogW1sxLDBdXQ0KfQ0K
{"typ":"JWT",
"alg":"ES256"
"x5t#S256":"cjGWIhDSkz7Jk6d7SnIDiYq3TN-XT_AtLePx7Hy53mg"}In order to produce the tbsPayload, we first need the base64url-encoded (without padding) JWT Header:
eyJ0eXAiOiJKV1QiLAogImFsZyI6IkVTMjU2IiwKICJ4NXQjUzI1NiI6IjcyMzE5NjIyMTBkMjkz M2VjOTkzYTc3YjRhNzIwMzg5OGFiNzRjZGY5NzRmZjAyZDJkZTNmMWVjN2NiOWRlNjgifQ
then we have to append a period (".") and the base64url encoding of the EncodedMetadataTOCPayload
(taken from the example in section Metadata TOC Format):
eyJ0eXAiOiJKV1QiLAogImFsZyI6IkVTMjU2IiwKICJ4NXQjUzI1NiI6IjcyMzE5NjIyMTBkMjkz M2VjOTkzYTc3YjRhNzIwMzg5OGFiNzRjZGY5NzRmZjAyZDJkZTNmMWVjN2NiOWRlNjgifQ. eyAibm8iOiAxMjM0LCAibmV4dC11cGRhdGUiOiAiMzEtMDMtMjAxNCIsDQogICJlbnRyaWVzIjog Ww0KICAgeyAiYWFpZCI6ICIxMjM0IzU2NzgiLCANCiAgICAgImhhc2giOiAiOTBkYThkYTZkZTIz MjQ4YWJiMzRkYTBkNDg2MWY0YjMwYTc5M2UxOThhOGQ1YmFhN2Y5OGYyNjBkYjcxYWNkNCIsIA0K ICAgICAidXJsIjogImh0dHBzOi8vZmlkb2FsbGlhbmNlLm9yZy9tZXRhZGF0YS8xMjM0JXgyM2Fi Y2QiLCANCiAgICAgInN0YXR1cyI6ICJmaWRvQ2VydGlmaWVkIg0KICAgICAidGltZU9mTGFzdFN0 YXR1c0NoYW5nZSI6ICIiLA0KICAgICAiY2VydGlmaWNhdGlvbkRhdGUiOiAiMjAxNC0wMS0wNCIg fSwNCiAgIHsgImFhaWQiOiAiOTg3NiM0MzIxIiwgDQogICAgICJoYXNoIjogIjc4NWQxNmRmNjQw ZmQ3YjUwZWQxNzRjYjU2NDVjYzBmMWU3MmI3ZjE5Y2YyMjk1OTA1MmRkMjBiOTU0MWM2NGQiLA0K ICAgICAidXJsIjogImh0dHBzOi8vYXV0aG5yLXZlbmRvci1hLmNvbS9tZXRhZGF0YS85ODc2JXgy MzQzMjEiLA0KICAgICAic3RhdHVzIjogImZpZG9DZXJ0aWZpZWQiDQogICAgICJ0aW1lT2ZMYXN0 U3RhdHVzQ2hhbmdlIjogIjIwMTQtMDItMTkiLA0KICAgICAiY2VydGlmaWNhdGlvbkRhdGUiOiAi MjAxNC0wMS0wNyIgfQ0KICBdDQp9DQo
and finally we have to append another period (".") followed by the base64url-encoded signature.
eyJ0eXAiOiJKV1QiLAogImFsZyI6IkVTMjU2IiwKICJ4NXQjUzI1NiI6IjcyMzE5NjIyMTBkMjkz M2VjOTkzYTc3YjRhNzIwMzg5OGFiNzRjZGY5NzRmZjAyZDJkZTNmMWVjN2NiOWRlNjgifQ. eyAibm8iOiAxMjM0LCAibmV4dC11cGRhdGUiOiAiMzEtMDMtMjAxNCIsDQogICJlbnRyaWVzIjog Ww0KICAgeyAiYWFpZCI6ICIxMjM0IzU2NzgiLCANCiAgICAgImhhc2giOiAiOTBkYThkYTZkZTIz MjQ4YWJiMzRkYTBkNDg2MWY0YjMwYTc5M2UxOThhOGQ1YmFhN2Y5OGYyNjBkYjcxYWNkNCIsIA0K ICAgICAidXJsIjogImh0dHBzOi8vZmlkb2FsbGlhbmNlLm9yZy9tZXRhZGF0YS8xMjM0JXgyM2Fi Y2QiLCANCiAgICAgInN0YXR1cyI6ICJmaWRvQ2VydGlmaWVkIg0KICAgICAidGltZU9mTGFzdFN0 YXR1c0NoYW5nZSI6ICIiLA0KICAgICAiY2VydGlmaWNhdGlvbkRhdGUiOiAiMjAxNC0wMS0wNCIg fSwNCiAgIHsgImFhaWQiOiAiOTg3NiM0MzIxIiwgDQogICAgICJoYXNoIjogIjc4NWQxNmRmNjQw ZmQ3YjUwZWQxNzRjYjU2NDVjYzBmMWU3MmI3ZjE5Y2YyMjk1OTA1MmRkMjBiOTU0MWM2NGQiLA0K ICAgICAidXJsIjogImh0dHBzOi8vYXV0aG5yLXZlbmRvci1hLmNvbS9tZXRhZGF0YS85ODc2JXgy MzQzMjEiLA0KICAgICAic3RhdHVzIjogImZpZG9DZXJ0aWZpZWQiDQogICAgICJ0aW1lT2ZMYXN0 U3RhdHVzQ2hhbmdlIjogIjIwMTQtMDItMTkiLA0KICAgICAiY2VydGlmaWNhdGlvbkRhdGUiOiAi MjAxNC0wMS0wNyIgfQ0KICBdDQp9DQo. AP-qoJ3VPzj7L6lCE1UzHzJYQnszFQ8d2hJz51sPASgyABK5VXOFnAHzBTQRRkgwGqULy6PtTyUV zKxM0HrvoyZq
The line breaks are for display purposes only.
The signature in the example above was computed with the following ECDSA key
x: d4166ba8843d1731813f46f1af32174b5c2f6013831fb16f12c9c0b18af3a9b4 y: 861bc2f803a2241f4939bd0d8ecd34e468e42f7fdccd424edb1c3ce7c4dd04e d: 3744c426764f331f153e182d24f133190b6393cea480a8eec1c722fce161fe2d
nextUpdate field
of the Metadata TOC specifies a date when the
download SHOULD occur at latest.x5u attribute is present in the JWT Header, then:x5u attribute has
the same web-origin as the URL used to download the metadata TOC from.
The FIDO Server SHOULD ignore the file if the web-origin differs (in order to
prevent loading objects from arbitrary sites).x5u attribute [JWS]. The certificate chain MUST be
verified to properly chain to the metadata TOC signing trust anchor according
to [RFC5280]. All certificates in the chain MUST be checked for revocation according
to [RFC5280].x5u attribute is missing, the chain should be retrieved from the x5c attribute.
If that attribute is missing as well, Metadata TOC signing trust anchor
is considered the TOC signing certificate chain.no) is less or equal to the number of
the last Metadata TOC object cached locally.MetadataTOCPayloadEntry).
For each entry:url. Some authenticator vendors
might require authentication in order to provide access
to the data. Conforming FIDO Servers SHOULD support
the HTTP Basic, and HTTP Digest authentication schemes,
as defined in [RFC2617].timeOfLastStatusChange and statusReport.
Update the status of the cached entry. It is up to the relying party
to specify behavior for authenticators with status reports that indicate a
lack of certification, or known security issues.
However, the status REVOKED indicates significant security issues
related to such authenticators.
Authenticators with an unacceptable status should be marked accordingly. This information is required for building registration and authentication policies included in the registration request and the authentication request [UAFProtocol].
hash of the metadata TOC object. Ignore the
downloaded metadata statement if the hash value doesn't match.This section is non-normative.
This section describes the key considerations for designing this metadata service.
Need for Authenticator Metadata When defining policies for acceptable authenticators, it is often better to describe the required authenticator characteristics in a generic way than to list individual authenticator AAIDs. The metadata statements provide such information. Authenticator metadata also provides the trust anchor required to verify attestation objects.
The metadata service provides a standardized method to access such metadata statements.
Integrity and Authenticity Metadata statements include information relevant for the security. Some business verticals might even have the need to document authenticator policies and trust anchors used for verifying attestation objects for auditing purposes.
It is important to have a strong method to verify and proof integrity and authenticity and the freshness of metadata statements. We are using a single digital signature to protect the integrity and authenticity of the Metadata TOC object and we protect the integrity and authenticity of the individual metadata statements by including their cryptographic hash values into the Metadata TOC object. This allows for flexible distribution of the metadata statements and the Metadata TOC object using standard content distribution networks.
Organizational Impact Authenticator vendors can delegate the publication of metadata statements to the metadata service in its entirety. Even if authenticator vendors choose to publish metadata statements themselves, the effort is very limited as the metadata statement can be published like a normal document on a website. The FIDO Alliance has control over the FIDO certification process and receives the metadata as part of that process anyway. With this metadata service, the list of known authenticators needs to be updated, signed and published regularly. A single signature needs to be generated in order to protect the integrity and authenticity of the metadata TOC object.
Performance Impact Metadata TOC objects and metadata statements can be cached by the FIDO Server.
The update policy can be specified by the relying party.
The metadata TOC object includes a date for the next scheduled update. As a result there is no additional impact to the FIDO Server during FIDO Authentication or FIDO Registration operations.
Updating the Metadata TOC object and metadata statements can be performed asynchronously. This reduces the availability requirements for the metadata service and the load for the FIDO Server.
The metadata TOC object itself is relatively small as it does not contain the individual metadata statements. So downloading the metadata TOC object does not generate excessive data traffic.
Individual metadata statements are expected to change less frequently than the metadata TOC object. Only the modified metadata statements need be downloaded by the FIDO Server.
Non-public Metadata Statements Some authenticator vendors might want to provide access to metadata statements only to their subscribed customers.
They can publish the metadata statements on access protected URLs. The access URL and the cryptographic hash of the metadata statement is included in the metadata TOC object.
High Security Environments Some high security environments might only trust internal policy authorities. FIDO Servers in such environments could be restricted to use metadata TOC objects from a proprietary trusted source only. The metadata service is the baseline for most relying parties.
Extended Authenticator Information Some relying parties might want additional information about authenticators before accepting them. The policy configuration is under control of the relying party, so it is possible to only accept authenticators for which additional data is available and meets the requirements.