An attestation’s format defines what data is contained in the attestation and how that data is organized. The different formats are designed to work with specific types of Authenticators, clients, and client platforms. Which format is used during registration is decided by the client platform (the application or browser directly interacting with the Authenticator). All or any subsection of the following formats can be set to this option which will force SKFS to only accept the attestation formats specified. Selecting only a subset can allow only specific platforms to authenticate or to handle the case that specific aaguids have been specified in the allowedAaguids option.

Allowed values:

• packed: The default modern WebAuthn compatible format. All of the following formats exists to fit specific Authenticator or client hardware specifications. Packed is the most versatile of attestation formats when it come for attestation types. It supports Basic, Self, AttCA types. Packed is also one of two formats that passes an Authenticator’s aaguid during registration along with tpm format. This means that if specific aaguids are specified in the allowedAaguids option then this format and/or tpm format must be specified.
• tpm: Used by Authenticators that have a Trusted Platform Module for cryptographic functionality. The built-in use of a TPM is an added level of security that other Authenticators might not have. A TPM is a computer chip whose dedicated purpose is to securely store artifacts such as passwords, certificates, and encryption keys. All three of these artifacts can potentially be used within FIDO2, depending on the Authenticator. Specifying tpm format allows the use of Authenticators with this added security feature to be used properly by the client platform. The tpm is one of the two formats that passes an Authenticator’s aaguid during registration along with the packed format. This means if aaguids are specified in the allowedAaguids option then tpm format and/or packed format must also be specified. Supports AttCA and ECDAA attestation types.
• android-key: Used when the client platform is Android. This format is based on Android key attestation, which is a native Android protocol for the creation, storage, and use of the cryptographic keys. By specifying this format Android devices that support Android key attestation will be able to perform operations against SKFS. Supports the basic attestation type.
• android-safetynet: Used when the Authenticator is a platform Authenticator based on an Android platform whose attestation statement is based on the SafetyNet API. SafetyNet is a service whose purpose is to detect system abuse to help determine if servers and applications are running on a genuine Android device. By specifying this option it allows SKFS to handle registration operations from devices that support this added device integrity check, making the operation all that more trustworthy. Supports the basic attestation type.
• fido-u2f: Used for U2F Authenticators. FIDO U2F Authenticators are legacy Authenticators that follow FIDO U2F protocol, a predecessor to modern FIDO2. Allowing this format will authorize these older Authenticators to be used. Also, since the client platform can define what attestation format will be used it is possible that the client platform might use fido-u2f even with a FIDO2 Authenticator. Supports basic and AttCA attestation types.
• none: Used when the Relying Party does not wish to receive an attestation.