Re: Details on Google's implementation of passkeys

Adam,  one question.  


For discoverable credentials on Android will the DPK have a safety net attestation or no attestation until there is a new format?  

Thanks. 
John B. 

Sent from my iPhone

> On Jun 13, 2022, at 4:57 PM, David Waite <dwaite@pingidentity.com> wrote:
> 
> 
> Thank you so much for sharing this information, Adam!
> 
> -DW 
> 
>> On Mon, Jun 13, 2022 at 1:34 PM Adam Langley <agl@google.com> wrote:
>> 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
>> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.