Re: [webauthn] Platform Errors for attestations. (#1697)

> suggest in WebAuthn that should enterprise attestation be requested in a call to navigator.credentials.create, and one cannot be provided, that fallback to direct attestation is the natural next step

This is implied by the current client procedures - as I interpret them - but not explicitly called out.

In [step 22 of §5.1.3. Create a New Credential](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#CreateCred-async-loop):

>5. Let _enterpriseAttestationPossible_ be a Boolean value, as follows. If `pkOptions.`[`attestation`](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#dom-publickeycredentialcreationoptions-attestation)
>    - **is set to [`enterprise`](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#dom-attestationconveyancepreference-enterprise)**
>        - Let _enterpriseAttestationPossible_ be `true` if the user agent wishes to support enterprise attestation for `pkOptions.rp.id` (see [step 8](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#CreateCred-DetermineRpId), above). Otherwise `false`.
>
>[...]
>
>10. Invoke the [authenticatorMakeCredential](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#authenticatormakecredential) operation on _authenticator_ with _clientDataHash, pkOptions.[rp](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#dom-publickeycredentialcreationoptions-rp), pkOptions.[user](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#dom-publickeycredentialcreationoptions-user), requireResidentKey, userVerification, credTypesAndPubKeyAlgs, excludeCredentialDescriptorList, enterpriseAttestationPossible, attestationFormats_, and _authenticatorExtensions_ as parameters.

Nowhere do the client operations say to throw an error in case the `publicKey.attestation` argument has an unknown value either, only to set _attestationFormats_ to `["none"]` if `publicKey.attestation` is `"none"`.

So `authenticatorMakeCredential` would simply be invoked with _enterpriseAttestationPossible_: `false`. So then in [`authenticatorMakeCredential`](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#sctn-op-make-cred):

>12. Let _attestationFormat_ be the first supported [attestation statement format identifier](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#attestation-statement-format-identifier) from _attestationFormats_, taking into account _enterpriseAttestationPossible_. If _attestationFormats_ contains no supported value, then let _attestationFormat_ be the [attestation statement format identifier](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#attestation-statement-format-identifier) most preferred by this authenticator.
>13. [...]
>14. Create an [attestation object](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#attestation-object) for the new credential using the procedure specified in [§ 6.5.4 Generating an Attestation Object](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#sctn-generating-an-attestation-object), the [attestation statement format](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#attestation-statement-format) _attestationFormat_, and the values _authenticatorData_ and _hash_, as well as [taking into account](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#dom-attestationconveyancepreference-enterprise) the value of _enterpriseAttestationPossible_. For more details on attestation, see [§ 6.5 Attestation](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#sctn-attestation).

so it is simply up to the authenticator to decide whether to return an enterprise or non-enterprise attestation (most likely the latter when _enterpriseAttestationPossible_ is `false`).

So I think the fallback behaviour is normatively prescribed, but implicit and rather buried. It wouldn't hurt to point it out explicitly, for example in the definition of the [`"enterprise"` attestation conveyance preference](https://www.w3.org/TR/2025/WD-webauthn-3-20250127/#dom-attestationconveyancepreference-enterprise).

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1697#issuecomment-2761229704 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 28 March 2025 12:26:25 UTC