- From: Shane Weeden via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Jan 2021 02:45:26 +0000
- To: public-webauthn@w3.org
> In some cases depending on the RP implementation and assumptions, it may lead to verification bypass reducing MFA authenticators to single factor. RPs have a responsibility to use the specification properly as well. I'm not buying that the above statement is accurate unless the RP is fundamentally broken. The only way "verification bypass" occurs is if an RP forgets to check for (and enforce) the presence of the uv bit in the returned authenticatorData when it is otherwise expecting uv to be performed. If UV is a policy of the RP for a particular assertion flow, then this should *always* be checked at the RP as part of response message validation, regardless of what options get passed down to the client to aid with the assertion ceremony. This is outlined already in step 17 of https://www.w3.org/TR/webauthn/#sctn-verifying-assertion I think perhaps it is fair to observe that `userVerification="preferred"` is not a good choice of a default, particularly so in the case of assertion ceremonies. In fact I would go further and suggest that the RP should always explicitly choose to set this (currently optional) parameter. That's a non-normative spec change which I would definitely support. I believe Chrome actually spits out a warning on the browser console when userVerification is not explicitly provided in a ceremony. -- GitHub Notification of comment by sbweeden Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1510#issuecomment-764195409 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:45:28 UTC