Metadata

Vendor metadata files contain characteristics of authenticators as a metadata statement by using a specific syntax.

FIDO2 metadata statement files describe one or more authenticators such that they can be used by the relying parties to validate authenticator attestation and prove the genuineness of the device model.

IBM® Verify Identity Access provides two methods by which metadata can be provided to the relying party engine.

Static Upload: One or more metadata files are uploaded to Verify Identity Access and can be applied to a relying party.
Metadata Services: The locations and connection details of external FIDO metadata services are configured. This provides a dynamic method to download an up-to-date metadata statement. One or more of these can be applied to the relying party.

Each of these is an optional configuration parameter when creating a relying party and they can also be provided together to act in a complimentary manner. If both are provided and contain common data, there is a configuration property (preferMdsOverStatic) that will define whether to use the static content or the dynamic metadata service content.

The order in which multiple metadata services is also important. If common data is provided by multiple metadata services, the data that is contained in the higher priority service is used first.

Static metadata

Vendor metadata files contain characteristics of authenticators as a metadata statement by using a specific syntax.

The following formats and their corresponding syntax are supported:

FIDO metadata statement: This metadata statement is JSON and follows the format as outlined by the FIDO Alliance.
Yubico metadata: Yubico have established their own metadata format (file extension .yubico).
PEM Certificate: PEM certificates (file extension .pem) do not provide any of the user experience advantages that other metadata statements do. However, they can be used to verify an attestation statement.
Upon registration, a device provides the server with its attestation certificate during the attestation ceremony. This certificate can be (optionally with metadata enforcement) used to verify the authenticity of the device against a metadata file.

Metadata Services

A metadata service (MDS) is a centralized repository of the metadata statement that is used by the relying parties to validate authenticator attestation and prove the genuineness of the device model.

It provides a method to ensure the metadata statement that is used by the relying parties is up to date and is not expired.

Multiple different metadata services can be configured and used together (along with static files) by the relying party.

Verify Identity Access internally uses the HTTPClientV2 class to make the connection and retrieve the metadata from the MDS. Some of the configuration of the client can be set when you are creating the metadata service. See Adding a new metadata service. The HTTPClientV2 advanced configuration is used for other entries and for entries that are not overridden. See Advanced configuration properties.

Note: The metadata blob that is returned by the metadata service requires a certificate to verify the signature. This certificate must be loaded into the truststore that is configured for the metadata service. For example, to use the fidoalliance metadata service, the certificate from valid.r3.roots.globalsign.com must be loaded into the truststore.

The following MDS-specific configuration properties can be set:

URL: The location for the metadata service where the metadata can be downloaded.
Retry Interval: If the downloaded metadata has expired, the relying party attestation validation attempts to download a new version from the metadata service. If the attempt fails, the download does not retry until the retry interval is reached. For example, if a relying party is making many validation calls, rather than each of these attempting to retrieve a new metadata statement the download does not occur again until the retry interval is passed.
Prefer metadata service over static metadata: If metadata exists for the same device in both the static metadata and dynamic metadata service, this determines whether the static file entry (false) or the metadata service entry (true) is used. If the same entry exists multiple times in either the static files or the dynamic metadata, the first entry that is found is used.