Re: Details on Google's implementation of passkeys

Discoverable credentials never worked on Android.  They will continue to
work the way they always have on windows for probably a year or so.

They did work with attestations on OSX and iOS for about the last year.
 With bugs so perhaps I never considered it stable.

So yes Apple is pulling a bit back.

I don't think asking Google not to release discoverable credentials as
multi-device untill DPK and attestations are done is reasonable.

No they are not useful for enterprise in my opinion but they are much
better for the majority of people using passwords on a daily basis.

To reduce the most harm they should not be held back.

I think talking about DPK too early has muddied the waters.

I am just trying to be practical.  DPK is not ready and may never be.

John B.

On Mon, Jun 13, 2022, 9:13 PM Matthew Miller <matthew@millerti.me> wrote:

> > 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 <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> 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>
> 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> 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>
> 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> 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> 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
>
>
>
>
>