[colinclerk]

Does the crowd on HN expect passkey support to become more ubiquitous in the future, similar to Google OAuth today?

I’ve been surprised at how few sites seem to be adopting rapidly since there are UX gains, but I suppose Google had a fairly slow trajectory as well.

[ttul]

Apple’s push is enough to convince me that this will be a default soon. Adoption has been slow because it takes some effort and the payoff isn’t immediately obvious. This new service from 1Password might start to change that. I expect others will follow with similar ideas.

[bombcar]

Apple Pay but for passwords!

It will take over slowly, especially if they handle the edge cases well. Explaining passwords to people is a pain.

[recursive]

Apple Pay definitely hasn't taken over. I've heard of it, but never used it. I don't understand exactly what it does.

If explaining passwords to people is a pain, just wait until you try to explain a passkey.

[bombcar]

The passkey needs to work like faceID does on apps, quietly, quickly, and without anyone even really noticing.

Apple Pay is nice when a website supports it AND it works, but those two are sadly vanishingly rare.

Works well on Apple's store, however.

[zht]

have you ever used a tap credit card?

[bombcar]

Yes but I’m speaking of using Apple Pay on websites.

[recursive]

Yes, I have.

[mooreds]

I think once the account recovery problems, aka "oh no, dropped my phone in a pond, now I can't login", are resolved, it'll take off.

I've used it for some sites and it is pretty cool to not have to remember anything. Fingerprint readers are a bit touchy, but seem to be getting better.

I also think that it is far far easier than a password manager, the current go-to secure solution today.

[CharlesW]

> I think once the account recovery problems, aka "oh no, dropped my phone in a pond, now I can't login", are resolved, it'll take off.

The same recovery methods used for passwords also work for passkeys, e.g. as sending a link in an email or text message to create a new passkey.

In the "oh no, dropped my phone in a pond" scenario, my passkeys are already synced across devices via the cloud, so I would not have to create new passkeys.

[mooreds]

> The same recovery methods used for passwords also work for passkeys, e.g. as sending a link in an email or text message to create a new passkey.

How does a site have your email address if you registered and logged in with a passkey? They only have that if you gave it to them. Maybe there's an Apple specific extension, but the WebAuthn spec (which is what passkeys are based on) doesn't require any contact info to be provided.

>In the "oh no, dropped my phone in a pond" scenario, my passkeys are already synced across devices via the cloud, so I would not have to create new passkeys.

That is not true for every set of passkeys/WebAuthn credentials, only for people using certain providers like Apple. But yes, if you have that set up, that handles it.

[aseipp]

> but the WebAuthn spec (which is what passkeys are based on) doesn't require any contact info to be provided.

This isn't an issue with the spec, it's an issue with account creation, account information, and recovery flow on part of the operators of the website. Those operators are already familiar with this dance. They will use information that is required for registration in order to provide account recovery, and yes, this will include an optional, or possibly mandatory, email address/phone number/whatever to do so.

Existing registration flows that already work and ask for this information will barely need to change, and most users of Passkeys will be adding them to these already existing flows, so it's practically a non-issue. Or at least no more than it already was.

[teeray]

Big tech is salivating over the vendor lock this will enable, so there will be a big push for it. I’m just hoping password managers will allow us to store the key material in them so that cross-platform can work.

[CharlesW]

> Big tech is salivating over the vendor lock this will enable…

This enables vendor lock-in as much as passwords do. That is to say, not at all.

Example: Chrome supports passkeys, but uses a Chrome-only passkey store instead of the OS one. So I have one passkey for Chrome, and another for macOS/iOS.

[account-5]

That's literally describing vendor lock in meaning you need manage multiple vendor locked passkeys for the same service which is ridiculous.

Passkeys are massively less flexible than passwords as it stands.

[CharlesW]

> That's literally describing vendor lock in meaning you need manage multiple vendor locked passkeys for the same service which is ridiculous.

It makes more sense if you don't think of passkeys as passwords and more like "SSH keys for muggles". Passkeys are definitely not vendor-locked — they're a standard, and so Google Account passkeys work with anything that supports passkeys.

If you're unhappy that Chrome doesn't leverage the macOS passkey store, that's completely valid and you can point your frustration in their direction. In practice, taking 30 seconds to create an additional passkey wasn't onorous.

When 1Password supports passkeys, I'll generate another passkey for it and then use that globally.

[lucianbr]

> In practice, taking 30 seconds to create an additional passkey wasn't onorous.

Almost every site requires an account these days. I am quite fed up with the number of accounts I need to have, in general. Now you are telling me I have to go through a process of creating passkeys for each site for each browser/mobile os? 30 seconds times 100 is pretty onerous.

Oh, you mean you reuse the same passkey for all services that require accounts? I'm sorry to tell you, that's impossible. You didn't understand how this works.

"The same passkey is never used with more than one site." from here https://developers.google.com/identity/passkeys

[toomuchtodo]

Yes. To enable in Auth0, it's two checkboxes. For something more bespoke it's a few days of engineering time.

https://techcrunch.com/2023/05/03/google-now-lets-you-access...

https://passkeys.directory/

(managing passkey rollout at a fintech for customer iam)

[timeimp]

Once Apple and Google have pushed it out with their mobile devices, things will move along fast.

I'd argue within 5-ish years you'll start encountering people who have never used a username + password combo at all.

Passkeys are the future - but how they will work across ecosystems remains to be seen (without a subscription)

[barkerja]

Passkey support has been on iOS since the release of iOS 16 -- so more than a half-year!

Google has actually had support for passkey for many many months now, but for whatever reason, waited to formally announce it until just recently.

Cross-platform is also already solved. See the FAQ directly from the FIDO Alliance: https://fidoalliance.org/passkeys/#faq

[howinteresting]

> If the user does not have their old device or a security key, then the RP can treat sign-in from the new device (which might be from a different vendor) as a normal account recovery situation and take appropriate steps to get the user signed in.

LOL. This is not a serious answer.

[vbezhenar]

> I'd argue within 5-ish years you'll start encountering people who have never used a username + password combo at all.

But can one register apple/google account without password with fresh phone on setup screen? What would happen if that phone would die? Apple often asks for icloud password in various places (which really surprises me, I mean it's Apple app on Apple device which logged in, why ask me about it).

It still looks to me like master password (which is google/icloud password) and other accounts are accessible with this master password. Just less friction: no need to copy random passwords around.