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.

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.).

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".

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.

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.

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.

Why does 1password need to 'lobby' for an export function though? They could just build one in their software?

But why can't bitwarden be its own provider? I don't understand the constraint there. I thought passkeys were fully open and anyone can be a provider?

There's been a bit of conversation about this online. During the most recent AMA, 1Password's passkey team shared this: https://old.reddit.com/r/1Password/comments/16to6x7/hey_redd...

> 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.

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.