W3C home > Mailing lists > Public > public-webauthn@w3.org > November 2020

Re: [webauthn] User verification policy leads to ambiguous usage situations. (#1510)

From: Shane Weeden via GitHub <sysbot+gh@w3.org>
Date: Mon, 02 Nov 2020 00:34:58 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-720179840-1604277297-sysbot+gh@w3.org>
Credentials are created during the registration ceremony, not used. I think you mean which *authenticators* may be used. Also I think it is important to separate out the capabilities of specific browsers based on their implementation level from the semantics of the WebAuthn spec. The specification itself makes no claims about what a particular browser will support, nor that the choice of userVerification setting will work with any particular browser and authenticator combination.

It is important for RPs to choose a policy that is appropriate for the use case being implemented. If the future use of the credential is not for "password-less login" scenarios, and is therefore for 2FA-scenarios there is no real point in having uv set to anything other than discouraged. Even with uv=discouraged some authenticators (particularly platform authenticators) will still solicit uv - again this is the browsers choice.

If there are both password-less login and 2FA scenarios targeted, then L2 of the WebAuthn spec has introduced residentKey=preferred (which I would also use with uv=preferred), and the credProps extension to deal with that. It doesn't mean that all browsers will implement it, but that is the way the spec is evolving to try to offer a single registration ceremony which catches "best available" authenticator coverage in a single registration ceremony.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 2 November 2020 00:35:00 UTC

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