--- url: 'https://www.corbado.com/glossary/attestation' title: 'Attestation' description: 'Learn more about attestation in WebAuthn / passkeys and discover its relevance in user authentication, along with its connection to FIDO metadata service.' lang: 'en' keywords: 'attestation' --- # Attestation ## What is Attestation? **Attestation** can refer to three things (often in spoken language they are used interchangeable although they mean something different if taken precisely): 1. Firstly and more generally, attestation in the cryptographic space is a term where one party "attests" cryptographically to a statement to another party. 2. Secondly, during the registration phase in WebAuthn an **attestation object** is created by the [authenticator](https://www.corbado.com/glossary/authenticator) and returned to the [Relying Party](https://www.corbado.com/glossary/relying-party). It is a container object which holds the following information: - [attestation statement format (`fmt`)](https://www.iana.org/assignments/webauthn/webauthn.xhtml) - attestation statement (`attStmt` - see below) - [authenticator](https://www.corbado.com/glossary/authenticator) data (`authData`) 3. Thirdly, in WebAuthn, an **attestation statement** is an optional element of the attestation object. This statement, when included, verifies certain characteristics of the [authenticator](https://www.corbado.com/glossary/authenticator) (device) involved in the attestation process. However, some device manufactures (e.g. Apple) do not offer an attestation statement because this aspect of the specification was not intended for passkey synchronization and fails to effectively verify security attributes when credentials can be synced across different devices (e.g. a passkey is created on an iPhone but also used on a MacBook as it is synced via the same [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain)). Characteristics that can be given when the attestation statement is provided: - Offer proof that a genuine and trusted device was used during authentication. - Provide details about the device’s origin, model, and other pertinent information. - Enhance security measures, especially in scenarios where the trustworthiness of the device is crucial (e.g. certain regulated industries like [healthcare](https://www.corbado.com/passkeys-for-healthcare)). The following process flow of the Registration shows the role of the attestation (object) in WebAuthn: ![The attestation object is a central part of the Registration in WebAuthn](https://www.corbado.com/website-assets/cs_1_1_registration_flow_e44a658ca7.png) ### Example of an attestation object ```json { "root": { "id": "QFPlQVypLmmx71e0tmS3IfCFky0", "rawId": "QFPlQVypLmmx71e0tmS3IfCFky0", "response": { "attestationObject": { "fmt": "none", "attStmt": {}, "authData": { "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc", "flags": { "userPresent": true, "userVerified": true, "backupEligible": true, "backupStatus": true, "attestedData": true, "extensionData": false }, "counter": 0, "aaguid": "00000000-0000-0000-0000-000000000000", "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0", "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...", "parsedCredentialPublicKey": { "keyType": "EC2 (2)", "algorithm": "ES256 (-7)", "curve": 1, "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM", "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw" } } }, "clientDataJSON": { "type": "webauthn.create", "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp", "origin": "https://passkeys.eu", "crossOrigin": false }, "transports": ["hybrid", "internal"], "publicKeyAlgorithm": -7 }, "authenticatorAttachment": "cross-platform" } } ``` In the screenshot above, no [AAGUID](https://www.corbado.com/glossary/aaguid) and no attestation statement is provided. Continue reading for a technical breakdown of the most important attributes. ## Key Takeaways > - Attestation refers to the process of one party cryptographically attestating a statement > to another party. > - The attestation object in WebAuthn is created by the authenticator and passed during the > Registration. It contains among others the [AAGUID](https://www.corbado.com/glossary/aaguid), > [credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle) and public key. > - The attestation statement in WebAuthn is an optional field in the attestation object > ensuring that a genuine device was used for authentication. --- ### Understanding the Essence of Attestation In [WebAuthn](https://www.corbado.com/webauthn), attestation ensures that user authentication is secure and transparent. With the attestation statement, you can make sure that a credential was created on a specific authenticator / device. ### Types of Attestation: These types of attestation refer to the **attestation statement** (not the attestation object). They are considered as a preference by the [relying party](https://www.corbado.com/glossary/relying-party) (so the authenticator can behave differently as it's only a preference). - **No Attestation (`none`)**: For cases where privacy is of utmost concern or synced devices are in play, this type provides no information about the device, ensuring the user's privacy is intact. Another reason to use this value might be to save roundtrip to a certificate authoriy (CA). `none` is also the default value. - **Indirect Attestation (`indirect`)**: The [relying party](https://www.corbado.com/glossary/relying-party) prefers to get an attestation but allows the client to decide how to obtain attestation statements. The client may replace the authenticator-generated attestation statements with anonymous attestation statements to protect the user's privacy. - **Direct Attestation (`direct`)**: This is the most transparent form. Here, the relying party tells the authenticator that it wants an attestation statement, so that the relying party gets detailed information about the device, including its brand, model, and other specifics. While it offers the highest transparency, it may raise privacy concerns in certain scenarios or might not be really usable for synced credentials. - **Enterprise Attestation (`enterprise`)**: The relying party wants to receive an attestation statement that can include unique identifying information. This type of attestation is typically used in businesses or organizations that want to keep track of specific devices / [authenticators](https://www.corbado.com/glossary/authenticator). Web browsers (user agents) should not provide this detailed attestation unless their settings allow it specifically for the requesting party. If the settings do allow it, the browser should tell the device when it's needed (at the start of the process) that this specific type of attestation is being requested. The browser should then pass on the device's unique ID and the attestation proof exactly as it receives them to the relying arty. ### Attributes of the attestation object The **attestation object** contains many attributes, here's a quick explanation of some selected attributes: #### attestationObject ```json "attestationObject": { "fmt": "none", "attStmt": {}, "authData": { "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc", "flags": { "userPresent": true, "userVerified": true, "backupEligible": true, "backupStatus": true, "attestedData": true, "extensionData": false }, "counter": 0, "aaguid": "00000000-0000-0000-0000-000000000000", "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0", "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...", "parsedCredentialPublicKey": { "keyType": "EC2 (2)", "algorithm": "ES256 (-7)", "curve": 1, "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM", "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw" } } ``` The **attestationObject** is a [CBOR](https://www.corbado.com/glossary/cbor) encoded object, containing information about the newly created credentials, the public key and other relevant data: - **fmt** represents the atestation format, as [authenticators](https://www.corbado.com/glossary/authenticator) can provide attestation data in different ways. It tells the server how the server should validate the attestation data. Allowed values are "packed", "tpm", "[android](https://www.corbado.com/blog/how-to-enable-passkeys-android)-key", "[android](https://www.corbado.com/blog/how-to-enable-passkeys-android)-safetynet", "fido-u2f", "apple" or "none". See details [here](https://www.iana.org/assignments/webauthn/webauthn.xhtml) - **attStmt** is the attestation statement. For passkeys, e.g. on [iOS](https://www.corbado.com/blog/webauthn-errors) or [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) devices, it is left empty as passkeys on [iOS](https://www.corbado.com/blog/webauthn-errors) or Android can be synced, and filled for other devices such as on Windows or [hardware security keys](https://www.corbado.com/blog/best-fido2-hardware-security-keys). - **authData** is a buffer of values containing the following data: ![authData contains a data like the rpId Hash or important flags](https://www.corbado.com/website-assets/cs_2_3_auth_Data_32c5cbba19.png) The [attested credential data](https://www.w3.org/TR/webauthn-2/#attested-credential-data) plays an important role here. It contains the: - [AAGUID](https://www.corbado.com/glossary/aaguid), - [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle) length, - [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle) and - Credential public key. #### attStmt (attestation statement) Contrary, to the attestation object above where `attStmt` was left empty for readability reasons, this is how a filled attestation statement would look like. ```json { "alg": -65535, "sig": "MBHX7qov53SWqqPYCrxE5fcoAeDI83a0DzVJ2-N1KI6IAaCGGvINAIFzTEn44F6giANKte-8yEMDZbvbgDG1weaRj7SqsVaTty-TEQ", "ver": "2.0", "x5c": [ "MIIFwDCCA6oIaK6tZ7M", "MIIG6zCCBNpG18-MCJrHyrpMT-ul7RgxE4dFxqcG59ftTXqJ1f-X_Lpo7K-d7OgKoQrUgzxgATz8YXtFAk3rE1cHXvW9W52V637eAihKn9-UKC0ijzVXrBGX4Iq1o1M0ZfR-tFoOn498xasMCTnharKiM562GBLVJtlvV3DMSLEBl5SfuGM-qYjQgTQknXccks9guCmNaN_b2fo1DisbufXfjM3DVaMqx7IJpSc3wAnxooMrAYGpPM" ], "pubArea": "AAEACwAw_c3Ousz865mUPx8O3w", "certInfo": "_1RDR4AXAniCekfsiDI" } ``` - `alg`: The alg property indicates the cryptographic algorithm identifier used by the authenticator for signing the attestation statement. - `sig`: The sig property contains the digital signature generated by the authenticator. This signature is used to verify the authenticity of the attestation statement. - `ver`: The ver property specifies the version of the attestation statement format. - `x5c`: The x5c array contains one or more X.509 certificates that form a certification path, which assists in validating the attestation. - `pubArea`: The pubArea property contains detailed information about the public key and the [authenticator's](https://www.corbado.com/glossary/authenticator) characteristics. - `certInfo`: The certInfo property typically includes information about the certification of the authenticator by a trusted party. #### clientDataJSON ```json "clientDataJSON": { "type": "webauthn.create", "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp", "origin": "https://www.passkeys-debugger.io", "crossOrigin": false } ``` Read more about `clientDataJSON` in the respective glossary article. #### transports ```json "transports": [ "hybrid", "internal" ] ``` The **transports**-property indicates mechanisms through which an authenticator can communicate with a client. Some common, sample value combinations are: - `"transports": ["internal","hybrid"]`: Passkeys can be used from the [platform authenticator](https://www.corbado.com/glossary/platform-authenticator) (e.g. [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Touch ID, [Windows Hello](https://www.corbado.com/glossary/windows-hello)) or via cross-device authentication (using [QR code](https://www.corbado.com/blog/qr-code-login-authentication) & Bluetooth). - `"transports": ["internal"]`: Passkeys can be used from the [platform authenticator](https://www.corbado.com/glossary/platform-authenticator) (e.g. [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Touch ID, [Windows Hello](https://www.corbado.com/glossary/windows-hello)) - No `transports` property set: default behavior which gives no indications. --- ## Attestation FAQs ### Why is attestation crucial in WebAuthn? Attestation (the attestation statement) in WebAuthn is important as it offers proof of the genuineness of an authenticator. It ensures that the authentication process is carried out by a trusted device, thereby safeguarding against potential security threats. ### Has the introduction of passkeys changed the role of attestation? Yes, as passkeys can be synced across devices (e.g. from iPhone to MacBook via Keychain), relying parties cannot really determine anymore which attested device is really logging into an app or website. Therefore, Apple and Google decided that for synced passkeys, they will not provide attestation statements anymore. However, to improve the UX for relying parties and give them the opportunity to recognize and display passkeys from the Apple and Google ecosystem (iCloud Keychain and [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager)), the AAGUID will be still provided (as long as attestation is set to `direct` or `indirect` in the WebAuthn server settings for the `PublicKeyCredentialCreationOptions`. See this [GitHub issue](https://github.com/w3c/webauthn/issues/1962) for details. ### What's the recommendation attestation preference setting for passkeys? If you want to integrate passkey authentication in your website and app, and want to offer your users a great passkey UX, you should consider the following. We assume you build your solution primarily for a scenario where most of your users use a Windows, [iOS](https://www.corbado.com/blog/webauthn-errors), macOS or Android operating system. Moreover, we assume that most of the passkeys (apart from Windows) are synced passkeys. As neither iOS, macOS nor Android send an attestation statement anymore, the real validation of an authenticator is no longer used (for Windows this still works, probably as Windows does not offer synced passkeys via [Windows Hello](https://www.corbado.com/glossary/windows-hello) yet). However, to get the AAGUID, e.g. for better passkey management in the account settings, we recommend to set the attestation preference to `indirect`, as this would still allow to get the AAGUID while the attestation statement is either sent (Windows) or not sent (iOS, macOS, Android). ### What is the connection between attestation and the FIDO metadata service? The FIDO metadata service provides a repository of metadata for various authenticator. During attestation, this service can be queried to fetch and validate details about the authenticator, ensuring accuracy and enhancing the trustworthiness of the process. The FIDO metadata service checks the attestation statement (not the attestation object). ### Are there privacy concerns with direct attestation? Yes, direct attestation (in the attestation statement), while offering the highest transparency by providing detailed information about the device, can raise privacy concerns in certain scenarios. It's crucial to assess the need for transparency versus privacy when choosing the type of attestation. ### How does WebAuthn ensure user privacy during attestation? [WebAuthn](https://www.corbado.com/webauthn) offers different types of attestations preferences – none, indirect, direct and enterprise. For scenarios where [user privacy](https://www.corbado.com/faq/ensure-gdpr-compliance-with-passkeys) is important, `attestation=none` can be employed, which provides no details about the device, ensuring the user's privacy remains protected.