GitLab

This changes the return type of FidoAuthenticator::Options() from
AuthenticatorSupportedOptions to
base::Optional<AuthenticatorSupportedOptions>.

The FidoAuthenticator subclass for the Windows WebAuthn API can
potentially talk to a number of different authenticators with
different capabilities and hence cannot return a sensible value for
this method. It previously returned a "maximum possible" Options
value; but that lead to a bug where GetAssertionHandler assumed it
could set the user verification requirement of a request from
"preferred" to "required" because the Windows authenticator reported
itself as having a PIN set up (while the actual physical device might
not even support PINs).

By returning an Optional, we make the Windows case more explicit.

The aforementioned bug is fixed by moving the "effective uv
requirement" computation for GetAssertion into
FidoDeviceAuthenticator.

For MakeCredential, we have a similar bug: Because
CtapMakeCredentialRequest only stores the UV requirement as a bool
rather than the full enum, we currently default to uv=false for
authenticators that *do* support UV (even in the non-Windows case),
which is wrong. I'm going to address this in an immediate follow up CL.

Bug: 898718
Change-Id: I3e40296578929c75585e820aa5764bd623e1fe79
Reviewed-on: https://chromium-review.googlesource.com/c/1321852
Commit-Queue: Martin Kreichgauer <martinkr@google.com>
Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606973}