Re: [webauthn] Same PRF regardless of UV? (#2337)

I agree that this should be fixed in the spec. I didn't push for it in #2298; but seeing how it's now considered a "bug" in GPM to not enforce UV, then I think it should be either enforced that UV is _always_ required or that different PRF outputs are returned when UV is not enforced.

On a slightly related note, I think the spec should forbid authenticator data from containing any "secret" data when associated with PRF. Technically nothing in the spec forbids this, but there are password managers (e.g., Bitwarden) that don't reject "unexpected" key-value pairs in the authenticator data. Unlike PRF in the client extensions which password mangers can just ensure is not sent, one cannot "scrub" out data from the authenticator data since it's part of the signature. Password managers are supposed to _never_ be sent the vault key, but this is violated if an authenticator embed secret information in the authenticator data.

GPM was [recently changed](https://issues.chromium.org/issues/430804950) to not include the following CBOR:

```js
{
  "prf": {
    "eval": {
      "first": <first input passed to PRF>,
      "second": <second input passed to PRF>
    },
    "enabled": true
  }
} 
```

This was changed since it was incorrectly assumed that GPM was sending PRF outputs in the authenticator data when in fact it was simply embedding the inputs; however even if it were sending the actual PRF outputs, it wouldn't violate the spec. You could argue that the issue lies with password managers that use a generic CBOR parser that ignore unknown key-value pairs, but I personally think it would be better for the spec to forbid it altogether.

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


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

Received on Sunday, 2 November 2025 00:01:38 UTC