Upcoming WebAuthn Changes in Chrome

Dear WebAuthn Adoption Community Group and WebAuthn Working Group,

We would like to give you an early heads-up of some changes to Chrome’s
WebAuthn implementation on Desktop that we’re planning to release as soon
as Chrome 108 <https://chromiumdash.appspot.com/schedule>.

First, as we have announced previously
<https://lists.w3.org/Archives/Public/public-webauthn/2022Sep/0164.html>,
Chrome Conditional UI is now enabled by default. And Chrome Settings
includes a UI that lets you manage your passkeys on Windows and Mac.

We are also updating the illustrations in the tab-modal dialog that Chrome
shows while a WebAuthn request is pending, and are changing instruction
strings in this dialog to refer to ‘passkeys’.

On macOS, Chrome has for a while now included its own platform
authenticator, which stores credentials on the local device and ties them
to the user’s Chrome profile. When creating a passkey on this platform
authenticator, the tab-modal request dialog now includes a prompt that
displays the user account information
<https://w3c.github.io/webauthn/#dictionary-user-credential-params>
associated with the request, before showing the “native” macOS Touch ID
prompt. When asserting a passkey from the macOS platform authenticator, the
prompt to select a passkey is now shown before the macOS Touch ID prompt.
All new credentials created on Chrome’s macOS platform authenticator are
now always created client-side discoverable
<https://w3c.github.io/webauthn/#client-side-discoverable-credential>, thus
aligning with the behavior of some other platform authenticators. Any
existing non-discoverable credentials on the macOS platform authenticator
continue to be non-discoverable.

Lastly, on Windows, WebAuthn UI is currently split between Chrome’s own
browser UI, which supports phones as authenticators, and the Windows
“native” WebAuthn UI, which supports FIDO security keys and the Windows
platform authenticator. We are now changing in which cases Chrome shows its
own browser UI ahead of the native Windows WebAuthn system dialog:

   -

   For create() request with residentKey=’required’ and for get() requests
   with an empty allowCredentials parameter, Chrome will show a browser dialog
   that lets the user choose between using a phone, or using a USB security
   key or Windows Hello through the native Windows UI.
   -

   For other types of requests, Chrome shows the Windows WebAuthn dialog
   immediately. Users wishing to use a phone for these requests must cancel
   out of the native UI first.


As alway, if you find anything broken, please file a bug
<https://crbug.com/new>!

Thanks,
Martin Kreichgauer for the Chrome WebAuthn team