Token registered with "User Verification" can't be used at "User Presence" level

[happydude]

Ran into a catch22 situation today where a person registered a passkey with Google Password Manager and the presenceLevel is set to 4 (UV), later when they try and use the key, Chrome pops up a dialog to use the passkey saved in the password manager.  I'm assuming since they only have to click continue the presenceLevel is 1 (UP) and that causes an exception.  I haven't been able to replicate the issue myself, but I did have a second person run into the same problem.

I wonder if there is a somehow a mismatch with userVerification getting set to required when they are creating, but is discouraged when they are authenticating?

In our environment we do not want password-less, I used css to hide the passwordless checkbox, so I don't think that is getting checked. I think that would be a problem though because that would set it to required and the 2FA login would set it to discouraged.

I wonder if password-less should be a config option so the userVerification could be consistent? Or maybe userVerification itself should be a config option?

[restena-sw]

When not ticking the passwordless option, the credential registration gets started with

userVerification: discouraged

https://github.com/simplesamlphp/simplesamlphp-module-webauthn/blob/master/public/assets/js/webauthn.js#L179

This is the most one can do; the enum simply has no more restrictive options to choose from, see

https://www.w3.org/TR/webauthn-2/#enum-userVerificationRequirement

Apparently, the Google Password Manager registers the credential initially with UV despite this being as discouraged as possible. Obviously, there is little we can do to influence this client-side behaviour.

From my understanding of what you write above, the user then authenticates at a website which sets uverVerification to discouraged, too, - and at that point, the password manager honours that and only sends back an assertion with UP but not UV.

It is not forbidden in the spec to register with a higher layer (i.e. UV) first, and then only authenticate with a lower (UP).

The current code in the module makes the deliberate decision to forbid that behaviour, see

https://github.com/simplesamlphp/simplesamlphp-module-webauthn/blob/master/src/Controller/AuthProcess.php#L166

You could comment out this check; I'm rather sure this will workaround the problem. Please confirm.

[happydude]

Good point, I didn't think about client ignoring the discouraged