- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Jan 2021 02:53:22 +0000
- To: public-webauthn@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