W3C home > Mailing lists > Public > public-webauthn@w3.org > January 2021

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

From: Firstyear via GitHub <sysbot+gh@w3.org>
Date: Thu, 21 Jan 2021 02:53:22 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-764197782-1611197601-sysbot+gh@w3.org>
The webauthn authentication challenge defines a verification policy for *all* possible credentials the user may use. This is incompatible with a scenario where you have verified credentials and unverified credentials. The webauthn spec should list in allowCredentials, in the credential descriptor, what verification level the browser should request from the credential. 

> RPs have a responsibility to use the specification properly as well. 

The specification does not make it clear which properties of a webauthn challenge/response are signed and verifiable, and which are not, which leads to ambiguity and a belief in properties of webauthn that may not hold. For example, userVerification, autenticatorAttachment, requireResidentKey, excludeCredentials, authenticatorTransport - these are all *hints* to the browser on how to behave, but as expressed in the specification, they appear to be able to provide strict *requirements* on the interaction. That can lead to an RP incorrectly assuming that userVerification is a trusted property, and that the response will reflect that request (and many other things).

I think that it would be very easy for an RP to implement this specification incorrectly, and I have already seen a number of these in the wild (which I have responsibility disclosed to the affected parties). This is part of the motivation behind re-opening this issue as I have found deployments that use uv=preferred without realising that it could be bypassed. 

The specification should be designed in a way that makes it difficult to use incorrectly, and able to express security requirements that are required for a modern IDM system.

Again, see my PR that addresses this with a suggestion on how to resolve this matter in the specification. 

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 January 2021 02:53:24 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:38:40 UTC