Re: Details on Google's implementation of passkeys

Why is the Apple authenticator's behavior being discussed so heavily on a thread started by Google that explains the Android and Chrome OS authenticator's behavior?

I'm not sure Adam nor Christiaan (nor I) can do much about Apple's platform authenticator decisions.

Tim



Tim Cappalli | m: +1 (617) 701-7149<tel:16177017149> • @timcappalli<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Ftimcappalli&data=04%7C01%7CTim.Cappalli%40microsoft.com%7Ccad2840b7314494414c508d9e8730405%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637796402967834334%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VkKlVfLAedEIX7o6CHwH9gMsUhpEbehNsGDXWFz2iM0%3D&reserved=0>

did:ion:EiBgPHSLu66o1hQWT7ejtsV73PfrzeKphDXpgbLchRi32w

________________________________
From: Matthew Miller <matthew@millerti.me>
Sent: Tuesday, June 14, 2022 12:12:59 AM
To: Shane B Weeden <sweeden@au1.ibm.com>
Cc: John Bradley <jbradley@yubico.com>; Christiaan Brand <cbrand@google.com>; Adam Langley <agl@google.com>; David Waite <dwaite@pingidentity.com>; public-webauthn-adoption@w3.org <public-webauthn-adoption@w3.org>
Subject: Re: Details on Google's implementation of passkeys

> People seem to be disappointed something they never had is not ready.

To Shane's point I have to disagree that enterprise RP's are asking for "something they never had." How can we say that their asking for a way to generate a "discoverable single-device credential on platform authenticators" is unreasonable when, until passkeys, it was straightforward to request one from `navigator.credentials.create()` with, for example, macOS' "legacy platform authenticator" in Safari?

For the following input:

```
"attestation": "direct",
"authenticatorSelection": {
  "residentKey": "required",
  "authenticatorAttachment": "platform",
},
"extensions": {
  "credProps": true
}
```

A discoverable credential is currently generated, and the BE and BS bits are both 0's.

But if an RP runs those exact options through macOS Ventura, it's being communicated that an RP would get a discoverable credential, but BE and BS will now be 1's without any way to get back to them being 0's.

I maintain it's unreasonable to not offer a means for getting double-zeroes back on day and date of passkeys launching. Telling RP's to wait "two years when the spec is done" is of course the most convenient path forward since it means passkeys can come sooner than later. However it feels irresponsible as writers and implementers of this technology to not aim for backwards-compatibility and then say it's the consuming enterprise RP's fault for being so unreasonable to ask for a way to get back to the way the API worked for at least the last two years.



---- On Mon, 13 Jun 2022 20:43:58 -0700 Shane B Weeden <sweeden@au1.ibm.com> wrote ----

Apple had, for a short time, an attested, discoverable, single device credential on the platform authenticator. That has pivoted to something else entirely and there is no way to opt in to the previous capability. I completely accept such a thing has never yet existed for the Google ecosystem, and do look forward to kicking the tyres and providing feedback. The challenge for deployments where account sovereignty must not solely be in the hands of the platform provider is that without attested DPK or similar, one may as well use a persistent cookie or other weak client-side device “fingerprinting” for implementing conditional MFA, or not do conditional MFA at all and just prompt for 2FA every time.



On 14 Jun 2022, at 5:16 am, John Bradley <jbradley@yubico.com<mailto:jbradley@yubico.com>> wrote:

This Message Is From an External Sender
This message came from outside your organization.

I think that is fine.  The problem is that people got there hopes up using DPK and attestation to create what is effectively a discoverable single device credential on platform authenticators.

I think it might have been better to say that we release multi-device passkeys with no attestation or DPK now and then release the extensions in two years when the spec is done and implementations are ready.

People seem to be disappointed something they never had is not ready.

It would be better to keep it simple at launch.

Just my opinion.

John B.

On Mon, Jun 13, 2022 at 7:46 PM Christiaan Brand <cbrand@google.com<mailto:cbrand@google.com>> wrote:
I will repeat what I said at the f2f: we think it’s more important to get *something* out there that folks can start to play with, than waiting until all the (arguably important!) features are there. Attestation is one such feature. Stay tuned.

On Mon, Jun 13, 2022 at 19:23 John Bradley <jbradley@yubico.com<mailto:jbradley@yubico.com>> wrote:
I think it needs to be considered single factor phishing resistant.

I don’t know if DPK without attestation is really useful.

It is defiantly better than a password and probably better than password plus SMS.

If the expectations are reasonable they are fine with no DPK.

John B.

On Mon, Jun 13, 2022 at 7:19 PM Shane B Weeden <sweeden@au1.ibm.com<mailto:sweeden@au1.ibm.com>> wrote:
If there is no attestation on the DPK, then it cannot be considered a trusted indicator of a device-bound risk signal and we’re back to WebAuthn with passkeys essentially providing only first-factor authentication.




On 14 Jun 2022, at 2:32 am, Adam Langley <agl@google.com<mailto:agl@google.com>> wrote:

This Message Is From an External Sender
This message came from outside your organization.

On Mon, Jun 13, 2022 at 5:25 PM John Bradley <jbradley@yubico.com<mailto:jbradley@yubico.com>> wrote:
For discoverable credentials on Android will the DPK have a safety net attestation or no attestation until there is a new format?

No attestation, by current plans.


Cheers

AGL