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

@Firstyear,

The impasse you find yourself at is because you're wresting with a 
policy problem on a forum where only 1 of the 4 required parties in a 
FIDO ecosystem has any sway in this conversation. Because of that, the 
evolution of various FIDO protocols and relative immaturity of FIDO 
adoption in enterprises, the answers are not clear. I agree the WebAuthn 
spec is extremely unreadable to RP application developers; but, then 
again, it was never intended for RP application developers, so one can't 
fault the WG for the inscrutability of their text.

The problem, as I read your requirements, is you're confusing 
implementations of two different FIDO protocols - U2F and FIDO2 
(CTAP+WebAuthn) - at different stages of their evolution to solve a 
policy problem.

As someone who has implemented a FIDO Certified U2F and FIDO2 server, 
and as a past business application developer (before working for the 
vendor community), here is how I would currently address the use-case 
you describe (see below). I anticipate in 2 years, my answer will be 
different because I anticipate convergence in browser capability and a 
bubbling up of "better practices" in this arena. In the meantime, don't 
deny yourself the power to educate your users to enable a better UX for 
them (unlike some of the biggest companies who currently support FIDO, 
yet prefer to keep their users ignorant to enhance their profits).

- If the business application has a policy where the user *must* be 
verified through 2 different factors (possession + (knowledge or 
inherence)), then make sure you educate your users on the SignUp/Login 
pages BEFORE they embark on the process. If they have an Authenticator 
that only tests for user-presence (touch-style Security key), then tell 
them they must ALWAYS supply a password as an additional factor of 
authentication even if some browsers prompt them for a PIN when they 
touch the Authenticator[1];

- If they have an Authenticator capable of UV (such as biometrics), then 
tell them it is sufficient for the application's needs. Walk them 
through the registration and authentication processes with pictures. If 
they choose the path of the Security Key, prompt them for the password 
BEFORE you send the FIDO challenge;

- If the business policy requires UV, the FIDO server must always verify 
that authenticatorData (Bit 2) ALWAYS asserts UV was performed. However, 
you must have educated your user ahead of registration that they must 
have an Authenticator that supports the policy - a mobile device or a 
Security Key with biometrics, TouchID, etc. This is a policy issue and 
its incumbent on you to take worst-case scenarios into account and guide 
the user through the process;

- If the business application chooses a policy that does NOT require 
user verification, then you know what to do - just leave UV at 
"preferred" and let the Authenticator do its thing - you're going to 
ignore Bit 2 in authenticatorData anyway.

Arshad Noor
StrongKey

[1] I recognize that different browsers behave differently with 
touch-style Authenticators - where some prompt for a PIN while others do 
not - but, this is a hangover of the legacy U2F (CTAP1) protocol and the 
tens of thousands of such Authenticators still floating around. In time, 
they will disappear and all browsers will likely prompt for PINs at some 
point; this ecosystem has just begun its journey, so you have to give it 
a few years. However, educating your users is always a win-win situation 
no matter where it ends.


On 1/21/21 1:29 PM, Firstyear via GitHub wrote:

> The point is I want this work flow:
> 
> ```
> present any webauthn token you own:
> if userVerified:
>     return
> else:
>     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.

Received on Friday, 22 January 2021 04:33:47 UTC