[webauthn] Conflict between WebAuthn and CTAP2 handling of userVerification mapping (#1306)

FabianHenneke has just created a new issue for https://github.com/w3c/webauthn:

== Conflict between WebAuthn and CTAP2 handling of userVerification mapping ==
As explained in [this comment by @akshayku](https://github.com/w3c/webauthn/issues/1123#issuecomment-448198487) and [this comment by @agl](https://bugs.chromium.org/p/chromium/issues/detail?id=1005744#c2), the current (non-public) version of the CTAP2 spec appears to demand that all `authenticatorMakeCredential` requests are made with `userVerification` set to `true` if the authenticator has UV configured, which is in conflict [5.1.3, Step 20](https://www.w3.org/TR/webauthn-2/#sctn-createCredential) of the WebAuthn spec.

To me this seems to be due to different points of view on user verification underlying the CTAP2 and WebAuthn spec:
In CTAP2, the scope of user verification, for example via client PIN, is the entire authenticator: In order to ensure that the same user is generating and using credentials, any sensitive operation (i.e. any call to `authenticatorMakeCredential` and any user-verifying call to `authenticatorGetAssertion`) requires the authenticator to be unlocked, e.g., by entering the PIN.
In WebAuthn, the scope of user verification is not discussed in detail, but could potentially be per credential. For example, a software authenticator backed by the Android Keystore could maintain both user-verifying and non-user-verifying credentials simultaneously, and both types of credentials could be added independently. In particular, an authenticator of this type could both be advertising that it is capable of user verification and handle `authenticatorMakeCredential` requests with `userVerification` set to `false`, which matches the behavior mandated by the current version of the spec.

The mismatch between the two approaches leads to rather unsatisfying workarounds, such as Chrome falling back to U2F to bypass PIN prompts for `authenticatorMakeCredential` requests which use none of the CTAP2-only features. 

A possible, partial solution to this issue that would require no major changes to any spec would be to add a WebAuthn extension (or, even better, an `authenticatorGetInfo` response map entry) that allows an authenticator to switch between the two modes described above. This could be called `userVerificationScope`, taking the value `authenticator` on low-power authenticators such as hardware security keys and `credential` on authenticators that are e.g. backed by the Android Keystore, macOS' TouchID or a generic TPM. The value `authenticator`, which would also be the default, would keep the current CTAP2 behavior, whereas the value `credential` would make the client follow the current WebAuthn spec.

I would be grateful for any feedback on this proposal and the general situation around this part of the two specifications.

Note: I do not have access to the current CTAP2 spec, so all of this may have already been solved in some other way by the FIDO alliance members.

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1306 using your GitHub account

Received on Saturday, 21 September 2019 16:29:12 UTC