Passkey transfer across ecosystems is still an unsolved problem, Linux support is lacking, Bitwarden's implementation hasn't launched yet, and there are host of ecosystem issues and caveats that people keep telling me will be ironed out in the future but haven't been ironed out yet. Meanwhile, Amazon botching its rollout is a symptom of the specification not requiring standardized implementations. It's a symptom of the FIDO Alliance just assuming companies will do a good job and won't break everything.
Ideally, this would be the point where the Alliance would step in and say, "okay clearly we need to standardize a lot more because y'all can't handle this much leeway in how you implement the standard." Ideally it would give the Alliance pause about other parts of the standard like attestation where they're also being painfully naive about how corporate implementations will go. But instead, the industry seems intent on barrelling forward with passkeys in their current state anyway.
Passkeys aren't ready to recommend to normal consumers yet. We still have yet to see any proof that the portability and lock-out problems are actually going to be addressed. Words are cheap, talk to me when there is an official spec for transferring passkeys between ecosystems and when adherence to that spec and allowing export is a requirement for certification. Talk to me when the services that allow only linking one passkey are barred from official certification until they fix the problem.
And people say fixes are coming, but nobody in the industry is waiting for them to come. It's not a priority for them. The major companies are showing that they are perfectly willing to recommend a product to consumers in a half-finished state at a point where there is literally no major implementation that allows transferring passkeys between ecosystems and where there serious caveats around linking passkeys to accounts. So what trust am I supposed to have in that? Don't tell me the FIDO Alliance cares about portability or ease of access; the companies involved do not consider lack of portability and access to be a blocker.
I consider it irresponsible to recommend passkeys in their current state and irresponsible for companies to be rolling out wide support based on the current state of the ecosystem. I've lost a ton of faith in the entire standard because of how advocates have glossed over issues and because of how the industry is currently showing that actual universal access and universal support and real Open implementations are not a requirement and that they're willing to try pushing consumers onto passkeys before those critical problems are fixed. The whole thing up to this point has felt dishonest and pushy and weird.
If the intent from advocates was to build support by papering over the problems, the effect has been the opposite. I'm still aware of the problems, but now I also don't trust the advocates to be honest when talking about the problems. At some point I need to sit down and write up something more detailed about what the timeline has looked like, because I really feel like the conversation around passkeys and the way companies have moved forward with them is a really good example of how to just completely kill consumer trust in a standard that could have theoretically been good.
I was really excited about WebAuthN, but even as somebody having read the specification several times and having done a lot of experimentation, it's now more or less a mystery to me when I can add which type of passkey to a given website.
Sometimes I get 1Password jumping in; as of lately, Chrome sometimes realizes that I have a native passkey stored in iCloud(!); until recently, there was also Chrome's local/non-synchronized passkeys on macOS; very often, nothing happens and I realize I'm just on the wrong browser for any of it to work (e.g. Firefox on macOS).
I can't realistically recommend this to non-technical friends and family at this point.
I was so excited about WebAuthN. Part of my irritation about passkeys is that I want to like them. It's a cool idea and they could in a parallel universe somewhere be really good. I wish the people working on them weren't systematically undermining my trust in the entire concept.
We have tried to offer / show an implementation of Webauthn-based cross-platform PassKey support over at mailpass.io, where you can mix and match your devices as needed to any one account. The only known limitation at the moment is Mac TouchId via Firefox, which is being worked on by FF community (but could take up to 20 years based on some recent bugfix times over there :\ )
> where you can mix and match your devices as needed to any one account.
I appreciate what you're trying to do and I'm happy for more providers to build implementations, but you can't individually solve the ecosystem problem because you're only one provider. You can't force Apple, 1Password, Google, and Microsoft to all allow import and export from your app. You can't force Amazon not to do attestation or to accept multiple keys, even if you do everything right you don't have the power to force them to go along with you.
This is a problem that has to be solved by the FIDO Alliance; individual providers can't solve it for them. The Alliance itself has to take some responsibility for the direction of the spec they're pushing and for the direction the industry is going. Ecosystem portability is not going to be solved until interoperability is as a mandated condition for certification.
Totally agree FIDO need to sort this out.
Until then, we developers can at least try to show a way forwards where Apple / Google do not own all of your PassKey access
Appreciated!
Shout out to MasterKale (https://github.com/MasterKale/SimpleWebAuthn) for a comprehensive Typescript wrapper for the spec.
The challenge was more around UX and thinking about "if we do not use a password at all, how does this work"
I just replaced all my OTPs stored in Authy by passkeys stored in iCloud Keychain. It works perfectly fine with both Safari and Chrome 118, and is synced between my Mac and iPhone with end-to-end encryption.
I’m using it with Google, GitHub, Facebook, Gandi, Fastmail, and Stripe. On some of these websites, the passkey is still seen as security key for 2FA instead of a “real” passkey not requiring a password at all.
Apple and Google are putting a lot of effort in making this work well and it shows.
> Apple and Google are putting a lot of effort in making this work well and it shows.
They're not putting in enough effort. Both platforms still have serious caveats that mean that passkeys are not ready for ordinary users and both platforms are still willing to push this technology on ordinary users before those caveats are solved. That makes me trust them less because if they tell me the technology is ready, I don't know if they're actually using me as a guinea pig or not.
The big caveat (but by no means the only one) is still that passkeys can not be imported and exported across ecosystems (and no, 1Password does not solve this problem, 1Password keys also can not be imported and exported across ecosystems).
And what we're seeing above from Amazon is that even if Apple and Google step up and allow export the ecosystem is still going to be fragmented and overcomplicated as long as the FIDO Alliance refuses to take responsibility for pushing companies to make good decisions about their implementations. The Alliance's deliberate hands-off approach to these problems is why the ecosystem is a fragmented disaster. I don't want to rely on the good will of Google, that's not good enough. These fixes have to be part of the standard itself.
> On some of these websites, the passkey is still seen as security key for 2FA instead of a “real” passkey not requiring a password at all.
This is exactly what I'm talking about, passkeys are designed to be an alternative to passwords, it is a weakness of the spec that they are being used by services as a 2FA token. That's not a positive place for the ecosystem to be, it's mixed messaging about what passkeys are supposed to be.
It makes passkeys less accessible to ordinary people if companies are not even aligned on what passkeys definitionally are supposed to be.
Agreed on the importance of passkeys "portability" (being able to import/export passkeys across ecosystems).
Edit: But don't we have the same problem with TOPT? I don't there is a standard letting us export/import TOPT keys from one system to another (like Authy, Google Authentication, Microsoft Authenticator, 1Password, Apple Keychain, etc.).
> Edit: But don't we have the same problem with TOPT
We do, and it is a problem. Google Authenticator is a good example, lacking both automatic export (at least it did last time I checked) and (until recently) lacking even backup within Google's own ecosystem. People got burned by Google Authenticator, and I think that is a contributing factor to why real 2FA didn't take off for the general public. 2FA usage is low and is mostly relegated to the tech community, ie people who are able to easily avoid the above issues.
Note that unlike passkeys, 2FA is also not intended to be a replacement for passwords. The use cases are a lot simpler and there are fewer things to be concerned about (for example, unlike with passkeys there generally isn't a need for services to support having multiple 2FA codes linked to the same account). A big part of why I'm comfortable with 2FA is that I don't have to onboard normal users, and the standard itself is so simple that I feel like I could implement it myself if I ever needed to, and unlike with passkeys there's virtually nothing any service could do to stop me.
But putting that all aside, if the idea behind passkeys is to be a replacement for passwords, they're going to need to do a lot better than TOTP did. I use 2FA, but I also notice that it is a frequent usability complaint from non-technical users and honestly from technical users too -- there was pushback when PyPi started mandating it for certain accounts. Passkeys have to be way better than 2FA if they have any hope of seeing wide adoption.
Also note that the export situation with passkeys is a lot worse than the export situation for TOTP ever was. Export for a 2FA app is usually unencrypted, you're basically just exporting a number. So while the lack of requirement to allow export was definitely a problem, the need for a standardized format (as nice as it would have been) was much lower because the format was kind of self-evident. With passkeys that's not the case; 1Password is currently holding off on export because they don't want to allow plain-text export of the keys and they want FIDO's input into how to do it. There wasn't ever a point with TOTP where implementers were saying "we can't export keys until we get instructions how to".
What happens if you use Windows, Mac, FreeBSD, Linux, Android (without Google account!) and iOS? Yes I use all of those daily.
All the implementations I've seen are walled gardens. We really need some self hosted option that is fully cross platform.
Besides the walled garden I definitely don't trust a big tech player with the keys to my entire online life. Besides tracking and telemetry concerns they can block me for any perceived "terms of service violation" usually without much recourse. Or even because I logged in from an unexpected location as recently happened to my Instagram.
Not so much a problem when I hardly have any data in Google. Huge problem when it's the key to everything else.
> We really need some self hosted option that is fully cross platform.
It needs to be supported by the big players too. A self-hosted option isn't enough.
A self-hosted, cross-platform and Open Source provider that's usable with existing services is a requirement for people who are comfortable with technology and who are familiar with the ecosystem to come on board. People like me need that. But if I'm going to advocate that ordinary people use passkeys, then it's not good enough that there would theoretically exist a provider that wouldn't lock them down.
As long as the default option that their OS is telling them to use is locked down and can't import or export, then the only advice I'm going to give them is "don't use passkeys." I'm not going to deal with a situation where they move phones and I have to tell them "oh, you would have been able to sync your passkeys across ecosystems easily, but you chose the wrong ecosystem to go with, so now you can't."
Inconsistent implementations and inconsistent providers will kill passkeys as a general tool.
> It needs to be supported by the big players too. A self-hosted option isn't enough.
But the way WebauthN works, it should be possible for any platform to offer this functionality. I believe 1password already offers cross-platform. But it's not self-hosted which is what I need.
Very common mistake that people make; there are two things that can be meant when people talk about "cross-platform":
1. The ability to use the same passkeys on a Windows/iOS/Android device. 1Password supports this, Apple is moving in this direction with its Chrome extension. Note that this isn't universally supported, but it's getting better over time.
2. The ability to move ecosystems entirely -- ie, the ability to export passkeys from iCloud onto a Windows computer, or to export passkeys out of 1Password into Bitwarden. No major platform supports this, not even 1Password (although they have at least said they're lobbying for it). As far as I know, there is no timeline for supporting this, and FIDO's current position is that they don't want to require it.
The second problem can't be solved by an individual provider, Open Source or not, because there's nothing in the spec requiring other providers to support export/import and no standard about how that export/import should happen. It has to be something that's tackled by the Alliance, and it can't be an optional part of the spec.
If users have to do research about which passkey provider is safe to use in order to avoid vendor lock-in, then I can't recommend passkeys to ordinary people.
----
This is a common confusion, and it's not helped by the fact that passkey advocates often conflate the two ideas; so people come into passkeys and think, "of course they're portable, everyone is telling me they're portable, everyone is telling me 1Password solved portability." But they're not portable; advocates are just using the most narrow definition of the word and are treating limited cross-device support and in-ecosystem backup as if those are the only things that matter. I've seen advocates argue that the problem of ecosystem independence is solved by Yubikeys even though Yubikeys are even less portable than roaming keys and more locked down. Not only can they not be exported to different non-Yubikey ecosystems, they can't even be backed up within the same ecosystem.
Bitwarden could theoretically get passkeys to the point where I would be OK using them because I'd only ever use Bitwarden's implementation and would self-host and the Open Source nature would guarantee that other people could read the data if I needed to move somewhere else. But Bitwarden can't get passkeys to the point where I'll recommend anyone else use them, because there is no way currently to use any other provider without suffering provider lock-in[0].
[0]: And no, before someone else comments otherwise, manually duplicating all of the keys across devices is not a reasonable or accessible strategy for avoiding lock-in.
> we never, under any circumstance, want to allow them to be persisted unencrypted. We don't want vendor lock in any more than you do, but getting everyone to agree on a common spec takes a while. We're trying the best we can to accelerate the process but please understand that defining secure specifications take time.
1Password's position is that it only wants to support export as part of shared standard, my understanding is that they aren't interested in exposing passkeys in a form where it they are unencrypted and the user can inspect them by hand.
1Password is pretty much the only voice I've heard talk about tangible plans for export (part of the reason I use the word "lobbying" to describe them is that they seem to be the member of the FIDO Alliance that I can find publicly advocating for a standard), but I suspect their position reflects the position of other FIDO Alliance members. Absent some evidence otherwise or some FIDO member giving some kind of information to the contrary, I'm assuming that we are not going to get export at all from any of the major providers until every provider agrees on a single standard, and short of individual providers like 1Password lobbying for that to be prioritized, I've seen no information about an official timeline or even any information about where in that process the FIDO Alliance is or whether other providers are interested in working towards that standard.
> But why can't bitwarden be its own provider? I don't understand the constraint there.
Bitwarden can be its own provider. If attestation doesn't go wrong (which is still a risk since lack of attestation for roaming keys is not standardized, we're relying on Apple's goodwill to block attestation on iOS), then Bitwarden will be usable with every service. However, my point is that having only one Open Source provider is not enough to make passkeys worth recommending to ordinary users.
Assuming everything goes well with Bitwarden their implementation might be enough for technical users like me who are familiar with the ecosystem and know how to avoid the many caveats, but ordinary users are going to be locked into proprietary platforms and ecosystems until the export/import situation is sorted for everyone. I can't recommend passkeys as a standard if there's only 1 provider that allows export/import and nobody else is required to work with them.
I don't want to have a conversation with my parents where they find out they can't move between ecosystems because they accidentally used their phone's built-in passkey provider. It's easier and safer to just tell them not to use passkeys.
----
As a side note it's worth mentioning that -- while I assume it will be possible -- I haven't actually seen any confirmation from Bitwarden that they are going to support export either. With an Open Source program it will be possible for someone to add support, but I can't actually say with complete certainty that you won't need to fork Bitwarden and program support yourself if you want to export passkeys. I can't with complete certainty say that someone using Bitwarden's official service instead of self-hosting will be able to export passkeys. I assume they will be able to, I assume there's a branch somewhere on a Github repo I could look at that would show that Bitwarden will allow some form of user-inspectable export.
But I haven't actually found that branch and I can't find any information about what exports will look like from Bitwarden or what format they're considering or if it's just going to be rolled into the existing data vault. If that information is online, it doesn't seem to be in an easily searchable place.
I assume export will be supported in Bitwarden and it'll just be another part of the vault. But it would be nice to get some info about it.
Ok now imagine that you would wan't to use an Android or Windows device in the future. How do you easily access your iCloud Keychain. Or that for some reason Apple blocks your account?
Yes, that's a drawback. If I want this, then I'll consider 1Password (or Bitwarden when they support passkeys).
I'm also not entirely comfortable with trusting Apple with this, considering the track record of some big tech with arbitrary blocking accounts, but assuming they block my account, then I would lose the cloud services (used for and syncing and backing up my passkeys), but I should still be able to use my passkeys locally on my Mac and iPhone. For that reason, I'm not sure what is the problem you're describing. It's not really different from 1Password arbitrarily terminating my account, or going out of business.
It's a good thing that these are not possible. I want private keys to be non-exportable. This is why HSMs and Yubikeys are so secure, because there is no API to access the private key itself. It prevents hackers from leveraging other exploits to extract private keys.
The only "transfer" process I want is one where I can use the passkey on one hardware device to authorize in real-time the login on a new device, so that I can then set up a separate passkey on that device. This is fundamentally an application concern and not part of the WebAuthn standard, because there needs to be something to push to the device with the pre-existing passkey to ask for authorization.
> It's a good thing that these are not possible. I want private keys to be non-exportable.
Cool, I guess, but they are never going to be a replacement for passwords as long as that's the case. Ordinary non-techie users are never going to be OK with that.
We couldn't get ordinary users to use real 2FA tokens. You think security people are going to convince them to build a backup system across multiple devices where they duplicate their keys? It's not going to happen.
> The only "transfer" process I want is one where I can use the passkey on one hardware device to authorize in real-time the login on a new device, so that I can then set up a separate passkey on that device. This is fundamentally an application concern and not part of the WebAuthn standard
This is absolutely something that concerns the WebAuthn standard, because a nontrivial number of providers don't support this.
I'm tired of the passkey advocates saying "backup works, you just have to authorize new devices" at the same time they're saying, "it's not our responsibility to ensure that it's possible to authorize new devices." Okay, it's not your responsibility, but then don't pretend that backup works even under the narrow criteria of cloning keys on multiple devices, because even that doesn't actually work.
Amazon above is spitting out an error code that claims it will only support adding one passkey per-provider. If so, that's the FIDO Alliance's problem to solve if the FIDO Alliance is interested in anyone actually using their spec, because my takeaway from Amazon's messaging is that cross-device registration isn't guaranteed to work.
Ideally, this would be the point where the Alliance would step in and say, "okay clearly we need to standardize a lot more because y'all can't handle this much leeway in how you implement the standard." Ideally it would give the Alliance pause about other parts of the standard like attestation where they're also being painfully naive about how corporate implementations will go. But instead, the industry seems intent on barrelling forward with passkeys in their current state anyway.
Passkeys aren't ready to recommend to normal consumers yet. We still have yet to see any proof that the portability and lock-out problems are actually going to be addressed. Words are cheap, talk to me when there is an official spec for transferring passkeys between ecosystems and when adherence to that spec and allowing export is a requirement for certification. Talk to me when the services that allow only linking one passkey are barred from official certification until they fix the problem.
And people say fixes are coming, but nobody in the industry is waiting for them to come. It's not a priority for them. The major companies are showing that they are perfectly willing to recommend a product to consumers in a half-finished state at a point where there is literally no major implementation that allows transferring passkeys between ecosystems and where there serious caveats around linking passkeys to accounts. So what trust am I supposed to have in that? Don't tell me the FIDO Alliance cares about portability or ease of access; the companies involved do not consider lack of portability and access to be a blocker.
I consider it irresponsible to recommend passkeys in their current state and irresponsible for companies to be rolling out wide support based on the current state of the ecosystem. I've lost a ton of faith in the entire standard because of how advocates have glossed over issues and because of how the industry is currently showing that actual universal access and universal support and real Open implementations are not a requirement and that they're willing to try pushing consumers onto passkeys before those critical problems are fixed. The whole thing up to this point has felt dishonest and pushy and weird.
If the intent from advocates was to build support by papering over the problems, the effect has been the opposite. I'm still aware of the problems, but now I also don't trust the advocates to be honest when talking about the problems. At some point I need to sit down and write up something more detailed about what the timeline has looked like, because I really feel like the conversation around passkeys and the way companies have moved forward with them is a really good example of how to just completely kill consumer trust in a standard that could have theoretically been good.