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.
It will take over slowly, especially if they handle the edge cases well. Explaining passwords to people is a pain.
If explaining passwords to people is a pain, just wait until you try to explain a passkey.
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.
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.
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.
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.
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.
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.
Passkeys are massively less flexible than passwords as it stands.
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.
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
https://techcrunch.com/2023/05/03/google-now-lets-you-access...
(managing passkey rollout at a fintech for customer iam)
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)
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
LOL. This is not a serious answer.
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.