- From: Shane Weeden via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Mar 2022 20:39:58 +0000
- To: public-webauthn@w3.org
> I'm still not sure what difference there is between "the RP requires user verification" and `userVerification` being set to "required". As a Relying Party implementor I'd still interpret the former as the latter. Consider that the RP has determined that for this creation or authentication that it wants UV. It sends a page to the browser with JS calling WebAuthn, and uv=required in the options. The RP cannot be certain at this point that the client (i.e. browser) actually then uses these options unmodified in the call to the authenticator. There can be reasons for this, such as: - a nefarious user who has acquired a victims authenticator but not the PIN might try to use it by intercepting the call in a browser debugger and modifying the JS. - The client might have a browser plugin that does same As a result, the RP should never "trust" that the options it sent to the browser were actually used in communications with the authenticator. Instead it should keep a "copy of its policy", which might be a local copy of the options it intended the client to use, and always verify the response from the authenticator against that. > In which scenario is it possible that these two are different? When the options are modified at the browser, after being transmitted in a page with JS from the RP, but before being used in communications with the authenticator. > * The RP requires user verification but doesn't set `userVerification` to "required": That seems unreasonable, the RP shouldn't reject a response without user verification if it didn't ask for it > * The RP doesn't require user verification but sets `userVerification` to "required": This sounds like the RP really should've set `userVerification` to "preferred" and not "required" then. > > Is there a use case that I'm not seeing? If there really is a reasonable one then I think it makes sense to point that out in the spec somewhere, so that library implementors don't equate these things. I think the important thing here is that what the RP thinks it sets as options needs to be policy/state stored at the RP and that responses are verified against that. How the RP maintains that policy is likely going to be a copy of the options sent to the client, but doesn't have to be. This is why the proposed language is used - to indicate the intent of the RP, rather than specifically saying what options were used in the actual WebAuthn call at the browser. Given this view of things, is your concern now addressed, or would you propose different text? -- GitHub Notification of comment by sbweeden Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1704#issuecomment-1063350512 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 March 2022 20:40:00 UTC