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

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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Thursday, 21 January 2021 02:53:24 UTC