Upcoming changes to Chrome’s WebAuthn implementation (Chrome 112 / 113)

Greetings WebAuthn Adoption Community Group and WebAuthn Working Group,


We would like to give you an early heads-up to some changes in Chrome’s
WebAuthn platform authenticator on macOS, and Chrome’s interaction with
FIDO2 security keys.


1-

On macOS, Chrome provides its own platform authenticator that stores
credentials in the user’s Chrome profile on the local device only. This
authenticator currently always performs User Verification
<https://www.w3.org/TR/webauthn-2/#user-verification> whenever it creates
or asserts a credential. I.e., it prompts the user for Touch ID, or for the
local device password when Touch ID is unavailable. Touch ID may be
unavailable because it isn’t supported by the device, or because it’s
temporarily unavailable, e.g. because the display lid is closed.


Starting with Chrome 113 <https://chromiumdash.appspot.com/schedule>,
Chrome’s macOS platform authenticator will no longer prompt for either
factor if the Relying Party sets the User Verification Requirement
<https://www.w3.org/TR/webauthn-2/#enum-userVerificationRequirement> for
the request to “preferred” or “discouraged” and Touch ID is unavailable. If
the User Verification Requirement is set to “required”, Chrome continues to
enforce user verification as before, and falls back to prompting for the
device password if necessary. The UV bit
<https://www.w3.org/TR/webauthn-2/#flags> in the response will faithfully
reflect whether user verification was performed or not.


This change minimizes user disruption flows in situations where Touch ID
cannot be used for user verification, and makes Chrome’s implementation
align more closely with Safari’s.


2-

Since some sites are setting uv=preferred to get this, more convenient,
behavior we’ve also been considering its interaction with security keys. If
a site does not require user verification on an assertion, and the user has
stored a credential on a security key, then physical possession of the
security key is sufficient to create a valid assertion. This is fine if the
assertion is a 2nd-factor, but surprising if the credential is the sole
authentication factor.


Chromium has long set credProtect
<https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#sctn-credProtect-extension>
to userVerificationOptionalWithCredentialIDList when creating discoverable
credentials, but some sites use a flow where the user enters their username
and the site makes a WebAuthn request with an allowlist. In this case,
physical possession of the security key gives access to the account, which
is probably undesired.


To address this, Chrome 112 <https://chromiumdash.appspot.com/schedule>
will set credProtect to userVerificationRequired when creating a credential
where residentKey is required and userVerification is preferred. Such
credentials couldn’t then be used in a uv=discouraged assertion.


Cheers,
Martin Kreichgauer for the Chrome WebAuthn team