Re: Details on Google's implementation of passkeys

Will this implementation suffice to pass a Captcha test?

Same question from another perspective: will passkey-supported
authentication flows include Turing test?

Will be happy for any pointers to discussion regarding Captcha and Turing
tests. My interest, to be blunt, is to eliminate the need for Turing tests
as they are a nightmare for people with disabilities.

- Lionel
UserWay
Member, Accessibility Platform Architectures Working Group W3C
https://UserWay.org

On Tue, Jun 14, 2022 at 07:57 Matthew Miller <matthew@millerti.me> wrote:

> > Why is the Apple authenticator's behavior being discussed so heavily on
> a thread started by Google...
>
> Yikes, thank you @Tim. I apologize, everyone, for going wildly off topic.
>
> @Adam Thank you for succinctly setting expectations for the eventual
> Android debut of passkeys, this is a phenomenal level of candor about
> Google's plans.
>
> > 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)...
>
> > We do not currently plan to support any form of passkey sharing in the
> initial Android launch...
>
> ...And thank you for spelling these out as well, it's nice to know ahead
> of time about implementation differences like this. This will all be useful
> in some upcoming discussions on Cisco's end as we adapt to these latest
> changes in the ecosystem.
>
>
>
> ---- On Mon, 13 Jun 2022 21:33:37 -0700 *Tim Cappalli
> <Tim.Cappalli@microsoft.com <Tim.Cappalli@microsoft.com>>* wrote ----
>
> 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 <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 <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
>
>
>
>
>
>
>
> --


Lionel Wolberger
COO, UserWay Inc.
lionel@userway.org
UserWay.org <http://userway.org/>
<https://userway.org>[image: text]