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

> Agree with @nadalin - the adoption community is the right place for this discussion.

I disagree. This is not an adoption issue, but a specification issue. 

> I do have a POV on the scenario:
> I would not try and implement such a scenario with a single WebAuthn call - it seems awfully prone to end user confusion.

I believe that it is more confusing to prompt a user first to which of their credentials they should use, rather than just "use any webauthn credential, then we work out what else you need next.

> When using TouchID, uv should be set in the authenticatorData if the user was verified, _even if_ the RP set discouraged for userVerification when offering it's parameters to the client.

Okay, let's assume then it's a second yubikey - something can won't always set UV. 

The point is I want this work flow:

present any webauthn token you own:
if userVerified:
    prompt for further factors

Today that's not possible to express in webauthn. Please just *read* the PR I sent. 

The fundamental issue seems to be that you believe that userVerification is a property of each *interaction* regardless of what credentials are involved. I am requested that userVerification is a property of the *credential* after registration. 

And this manifests that in registration you express a userVerification policy for the *single* credential involved. But in authentication you must express a policy that encompasses *all possible* credentials that could be used. This eliminates the possibility of mixed verified and unverified credentials in a webauthn operation, and the RP making further decisions based on that. 

The extension I propose in my PR allows both to work. 

If you still believe it's not an issue, then close this issue. I believe that I have expressed the situation clearly, multiple times, and if you still disagree, then I do not believe it is worth continuing this discussion any further. 

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 21:29:58 UTC