Passkeys so far look like a repeat of previous efforts to move away from passwords or make logins more secure (e.g. Openid, webauthn, 2FA).
There are two problems:
1) this stuff is hard to explain to end users. This is the reason it's not widely used yet even on the handful of platforms that provide this option.
2) Big companies are being very proprietary and selfish about this stuff. So you have Google insisting on Chrome and Google password manager and insisting this all gets routed via your phone. And Apple does the same with Safari and their password manager. And of course MS is doing their own thing. Meanwhile, Firefox doesn't even support this stuff properly yet so it's impossible to roll out something that only supports passkeys and nothing else.
The second one is the big problem because companies like Google and Microsoft get all starry eyed when they realize that all passkey approvals go via property they control. So, they have a natural tendency to prevent people from using anything else than that. The same happened with OpenID. Both MS and Google were all over it. But they couldn't bring themselves to federate each other's identities. I mean people signing into gmail with a hotmail address or vice versa. The thought alone was causing panics at executive levels in both companies. So, they crippled it and over complicated it. And then proceeded to waffle on the standards so they could have mutually incompatible implementations be standard.
The problem isn’t the lack of an API, but rather the default being to store passkeys in an unexportable format in Apple’s or Google’s password safes.
Unsophisticated users are very likely to inadvertently lock themselves into their current platform with passkeys. Passwords can be copy-pasted over to a new password manager, worst case.
Apple's is also not un-exportable. I've twice exported my password database to try other password managers.
Apple's built-in is now approaching the level of a full password manager rather than just keychain sets. Entries can be mapped to multiple sites/hosts, it supports TOTP, and shared sets. Even "plays well" with third party managers but I wouldn't recommend that, it gets confusing.
> Apple's is also not un-exportable. I've twice exported my password database
Well, have you tried exporting a passkey? Passwords and passkeys are not the same thing in Apple's implementation, and I don't think there is a way to export the latter by design.
I think they can be shared via AirDrop these days, but that doesn't provide a migration path out of their walled garden since I think that process is mediated by Apple somehow, i.e. it's not just a JSON-encoded private key or anything like that.
Unfortunately Apple have been pretty bad about updating their "Apple Platform Security" document, which is where they'd normally share such details, so I haven't been able to figure out how "passkeys over AirDrop" actually work under the hood and whether there's a path to cross-vendor migration there.
> I've twice exported my password database to try other password managers.
Have you done that on just an iPhone? Last I checked you need a Mac. So iPhone users have to by another Apple product to leave the Apple ecosystem in way that doesn't require you to unlock your password settings multiple times to transfer each password.
> Firefox doesn't even support this stuff properly yet
What OS are you referring to? It works perfectly on macOS now, and I believe Windows has been supported even longer.
> The same happened with OpenID. Both MS and Google were all over it. But they couldn't bring themselves to federate each other's identities.
I wouldn’t call this a comparable situation. Passkeys are very interoperable (save for sites doing incompetent browser sniffing, “sorry, Firefox does not support passkeys” etc.), but there is a factor of platform lock-in.
Not great, but much more feasible to address since any fix can be done purely on the implementation backend without changing the API.
Not sure it's that hard to explain the basics. Passkeys are like very big passwords that password manages store for you, only with extra features. I don't think you need to touch on the public key encryption side of it.
Big Tech don't insist on their solutions, they just default to it which I think is fair.
Also WebAuthN is passkeys from what I understand. Not a previous effort.
That about summarizes the problem. It's definitely related to webauthn. But not the same thing. Which is why Firefox supports one but not the other (yet, I believe they are working on it). You could do webauthn without a hardware dongle but nobody seems to want to implement that until passkeys. Now your phone effectively becomes the hardware dongle. And if you then get rid of passwords, you are down to one factor. You had better not lose your phone, just saying.
Big Tech insists on their version of the tech which makes them the center of your universe, at the cost of their competitors and their users. Which is why we still have password logins everywhere. The solutions to move away from that have been around for some time. But big companies can't agree with each other on how to do this such that they don't lose users to each other. So, MS pretends to be the center of your world. So does Google. And Meta. And of course Apple. And a few others. And when you setup 2FA you are guided to use the Google Authenticator. Which of course annoys the hell out of competitors who then do something else or only reluctantly support 2FA or come up with some wacky scheme to do something with SMS.
Passkeys look like they are more of the same so far.
Passkeys are just a catchy (or confusing, depending on who you ask) name for a specific type/profile of WebAuthn authenticator (discoverable platform authenticators to be precise).
Firefox does support them on Windows and macOS, just like physical cross-platform authenticators (i.e. “Yubikeys”).
> And if you then get rid of passwords, you are down to one factor
I agree this is a bit of a shame. I'm hoping platforms support using passkeys with other factors.
> You had better not lose your phone
You can sync passkeys between devices and backup to a cloud.
> big companies can't agree with each other on how to do this
This was the case 18 months ago, I'm not so sure it is anymore. On my Google account I can setup a passkey passwordless login with a 3rd party password manager. I can do the exact same thing with my Microsoft account. There are still rough edges, for example to setup the passkey on MS I had to select the method "Use your Windows PC" but it all works.
Is it? While I'm a developer I have zero knowledge about passkeys. (haven't even read the linked article. Which is usually not a badge of honour, but in this case ensures that I'm as much an end user as one can be.)
I logged in with some website on my phone. The website asked me if I want to use passkeys and told me that means I can log in using my fingerprint/face id. I clicked yes. Scanned my face as I always use to open my phone. That site is now authenticating with my face.
Didn't feel like it was hard to explain to me. It felt all quite straightforward to be honest.
> How do they switch from iOS to Android and vice versa without losing access to all accounts?
Use your password. Or if you can't use it use the "I forgot my password" process.
> Can I login on my friend's phone using my face? Yes, because it's authenticating my face, right?
They can try if they have this question. I wouldn't expect it to work because it is my phone who knows my face and not the website. But if that is too much thinking for an unsophisticated user they just try it and see that it doesn't work.
> What happens if I lose access to my iCloud or Google account?
You use the "Forgot my password" process of the site.
> Why does website X say "your browser does not support passkeys", but it works on website Y? Is Firefox really bad? Do I have to switch to Chrome?
As an unsophisticated user my phone have none of these things.
> please don't use any assumptions you might have about these flows from your background knowledge as a developer.
That is a bit like asking to not think of a pink elephant. But also I haven't thought of any of these questions as I was enrolled using my passkey. (Nor did I think about these questions ever since even once.) So I would suspect worrying about these questions is not the primary reason why people use or don't use passkeys.
Because passkeys are replacing my password, right? Also, I think if I don't ever have to provide it on a regular basis, I'll eventually forget it.
> Use your password. Or if you can't use it use the "I forgot my password" process.
Why should I use passkeys then if I sometimes need my password anyway?
> They can try if they have this question.
Ok, I tried it and it doesn't work. Is that my fault or the site's? I'm confused – will your support be able to help me out?
> Nor did I think about these questions ever since even once.) So I would suspect worrying about these questions is not the primary reason why people use or don't use passkeys.
These concerns aren't about people not using passkeys, quite the opposite: They're about sharp edges that people usually only hit months or years into using a new authentication method.
> These concerns aren't about people not using passkeys, quite the opposite
The person who I responded to said:
“this stuff is hard to explain to end users. This is the reason it's not widely used yet even on the handful of platforms that provide this option.”
They clearly think “hard to explain” is the reason why they are not more popular. That is what i responded to. You are making an orthogonal point about trickyness of account recovery. (One i largely agree with, but has nothing to do with the ease of explaining passkeys)
I'm not sure "fall back on the existing method" is really an explanation though. It's like saying, "stick shift is easy to explain, whenever you're confused just switch back to standard."
Passkeys are meant to be a password replacement. "Use your password" can't be the answer to "how do I do X with passkeys"? We're talking about onboarding people onto a separate system, they're going to want to know why they're being asked to use two systems simultaneously.
Platform operators do think about support load and edge cases like the ones I've mentioned, and so to them these are obstacles to deploying passkeys. "How can I explain passkeys to my user?" covers more than just the happy path.
There are two problems:
1) this stuff is hard to explain to end users. This is the reason it's not widely used yet even on the handful of platforms that provide this option.
2) Big companies are being very proprietary and selfish about this stuff. So you have Google insisting on Chrome and Google password manager and insisting this all gets routed via your phone. And Apple does the same with Safari and their password manager. And of course MS is doing their own thing. Meanwhile, Firefox doesn't even support this stuff properly yet so it's impossible to roll out something that only supports passkeys and nothing else.
The second one is the big problem because companies like Google and Microsoft get all starry eyed when they realize that all passkey approvals go via property they control. So, they have a natural tendency to prevent people from using anything else than that. The same happened with OpenID. Both MS and Google were all over it. But they couldn't bring themselves to federate each other's identities. I mean people signing into gmail with a hotmail address or vice versa. The thought alone was causing panics at executive levels in both companies. So, they crippled it and over complicated it. And then proceeded to waffle on the standards so they could have mutually incompatible implementations be standard.