Details on Google's implementation of passkeys

We were excited to see Apple's passkey announcements at WWDC last
week. They have prompted several questions about the technical details
around what Google [demoed at
I/O](https://www.youtube.com/watch?v=xghjqgj4peA#t=9m00s) earlier this
year, and whether there are differences with Apple’s implementation.
This note is intended to help answer some of those questions:

Neither Android nor Chrome OS currently support discoverable
credentials. When we launch passkey support for Android, discoverable
credentials will be supported and discoverable credentials will be
passkeys: synced to the user's account. But non-discoverable
credentials will remain untouched. When a non-discoverable credential
is created it will continue to be hardware bound, and a SafetyNet
attestation will continue to be returned.

Unless credentials are currently being created on Android that set
residentKey=preferred then the introduction of passkey support is not
expected to have any immediate impact for existing applications(*).

Passkey support on Chrome OS will come after Android but our current
thinking is that it will use the same pattern for deployment:
non-discoverable credentials are bound to the ChromeOS device,
discoverable credentials are synced to the user's account.

Android & Chrome OS will sync passkeys with the user’s account and
creating a passkey will require syncing to be enabled. We do not
currently have plans to sync passkeys to other platforms.

Passkeys on Android will not initially have any attestation. If we add
an attestation in the future it will be in a new format that is common
across different Google products. The attestation for non-discoverable
credentials will likely transition to this new format in the future.

When we launch passkey support on Android we will concurrently launch
support for the [device public-key
extension](https://github.com/w3c/webauthn/pull/1663). This extension
associates a second private key with a credential and that private key
never leaves the device. This provides a device bound signal for risk
analysis. We believe that most sites should not use this extension,
but we understand that in some contexts the additional signal is
valuable.

We do not currently plan to support any form of passkey sharing in the
initial Android launch. Sharing needs to be carefully considered but
we recognise the need for users to move between ecosystems. As noted
above, we will support the device public-key extension to provide a
risk signal.

Auto-fill integration with passkeys is currently behind a flag in
Chrome on some platforms, and we demoed it at the RSA Conference last
week. The Web API for that integration differs from what Apple has
shipped in macOS and iOS betas but that will be resolved when Chrome
updates to reflect the [current
specification](https://github.com/w3c/webauthn/pull/1576). The
specification is still a draft and may change between now and public
availability.


(*) Android apps (not websites) that aren’t following the spec and
which are setting residentKey=required without also setting
requireResidentKey=true will also be affected. This combination of
options should be rejected but, due to a bug, is not.

---
Adam Langley
Principal Software Engineer
Google LLC

Received on Monday, 13 June 2022 19:34:20 UTC