- From: philomathic_life via GitHub <noreply@w3.org>
- Date: Wed, 12 Nov 2025 16:05:35 +0000
- To: public-webauthn@w3.org
> I would argue that an implementation cannot include any (authenticator) extension output fields that are not defined by the extension definition in the spec. Since the prf extension is a client-only extension, it by definition doesn't have any authenticator extension outputs. That's simply not true. The PRF extension explicitly states that it is "abstract over the authenticator implementation" (i.e., no direction at all about what, if any, authenticator extensions may exist). We know that when CTAP authenticators are used, `hmac-secret` and `hmac-secret-mc` authenticator extensions are used. This mean non-CTAP authenticators are able to use whatever, if any, extension they want. FIDO mandates that `hmac-secret` and `hmac-secret-mc` are encrypted at least; however there is no such protections when using non-CTAP authenticators. This means when the PRF extension is requested, it is spec-compliant for a non-CTAP authenticator to embed an extension `foo`/`prf`/\<whatever> and for the contents to be the value in `results`. You'd _hope_ that such an authenticator would instead encrypt the contents à la CTAP authenticators, but there is no such guarantee. -- GitHub Notification of comment by zacknewman Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2359#issuecomment-3522699784 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 November 2025 16:05:36 UTC