W3C home > Mailing lists > Public > public-webauthn@w3.org > June 2022

Re: [webauthn] Should an RP be able to provide finer grained authenticator filtering in attestation options? (#1688)

From: Chad Killingsworth via GitHub <sysbot+gh@w3.org>
Date: Tue, 07 Jun 2022 12:10:14 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-1148580815-1654603812-sysbot+gh@w3.org>
> If I initiate a navigator.credentials.get operation (without an allowCredentials list), and already have a passkey registered, Safari will automatically default to using the passkey. Similarly with Chrome, if I have a discoverable platform credential created (at least on my Mac), and initiate a navigator.credentials.get operation, that is automatically preferred. Note that these are browser implementation decisions, not something controlled by options supplied by the RP, but I think that's behaving the way you want?

It is. However it makes me somewhat uncomfortable to be completely reliant on the user agent behavior. I'd much prefer the spec to address this directly.

> This can already be technically achieved using the allowCredentials option. At the time of attestation you record enough information to know this credential is of the particular criteria you want, and only populate allowCredentials during assertion with the ID's of credentials which match your selected criteria.

This is true but requires you to first identify the user. The case I'm discussing is where the webauthn ceremony is initiated without any user context. In that scenario the user authenticates with the device, then chooses which pre-saved webauthn credential to send back to the server (Biometric then saved user info).

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 7 June 2022 12:10:15 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:46 UTC