> Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone

The google password manager and Apple devices will sync private keys as part of the password manager sync fabric. They are on all devices.

In addition, the 'share password' option on Apple devices works with passkeys. To deter social engineering, the person needs to be in your contacts, and in proximity to receive an airdrop.

There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.

> The google password manager and Apple devices will sync private keys as part of the password manager sync fabric.

This is really misleading -- you can not move a passkey "vault" from an Apple device to an Android device without doing a per-password operation. There are no Open implementations of a passkey authenticator and there is no standard format defined in the spec for how to do mass movement.

There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present?

I mean, you bring up Airdrop. I feel like I need to check, is something changed and that now works on Android devices? I'd love to be wrong about this, but Apple's documentation doesn't mention airdropping a passkey to an Android device: https://support.apple.com/guide/iphone/share-passkeys-passwo...

That kind of platform lock-in seems like it would be an important caveat to mention when talking about backup. But I never see stuff like this mentioned.

I don't see how anyone could genuinely claim that passkey portability is exactly the same as an SSH key or password. That's just not true. Authenticating a second device per-site is not the same thing as a cross-platform backup.

> They are on all devices.

They're not on a Linux desktop. If you want to use passkey on a Linux desktop, your options are to authenticate through a secondary proprietary device or to use a Yubikey -- for all practical purposes a locked down device which can not be backed up (no, buying a second Yubikey and manually adding it site-by-site is not the same as backup).

> There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.

And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.

And again, nothing in the spec requires it. This is asking for vendor lock-in. If it's not a big deal and everyone's going to support syncing across ecosystems, then it shouldn't be a big deal to add a standardized API and sync format to the requirements for being a certified provider.

> There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present?

I don't really see how this is different from the existing market of password managers, of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.

Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?

> And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.

There also hasn't been anyone yet who has tried to define what that interchange format should be.

> And again, nothing in the spec requires it. This is asking for vendor lock-in.

There are a broad range of passkey providers, from open source hardware to FIPS certified solutions to solve government compliance requirements. Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.

But those government agencies are specifically investing in that hardware because it _doesn't_ lock them into one vendor. Any other vendor who can meet their security requirements can sell into that space.

> I don't really see how this is different from the existing market of password managers, of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.

Do you really not see the difference here? Passwords are inherently resistant to vendor lock-in in a way that passkeys aren't. And honestly, not to call you out but we're back on this again:

> of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.

This is not representative of what the ecosystem actually looks like.

Apple and Google have announced zero plans beyond "we're looking into it" to allow open interchange with arbitrary 3rd-party clients. Chrome on Linux doesn't even support native passkeys at all. The most hopeful development I've seen in this space is Bitwarden. 1Password was billed as the solution, but I don't see any plans from 1Password to support porting to other password managers.

And any of these platforms blocking 3rd-party syncing is a big deal. If even just iOS decides "no, we won't allow that", that alone is a huge vendor lock-in that needs to be acknowledged.

So what plans can you point me towards where Google/Apple is announcing that they're going to build a generic API for exporting passkeys from the phone? Do they have a timeline up? And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.

> Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?

My worry is that most of them won't, and that hardware attestation will get rid of the rest. Let's say there is a client that supports moving passkeys around. That still doesn't change the lock-in potential for all of the clients that don't, it doesn't mean users will be able to migrate to that client once they've been locked in. It doesn't mean that services won't block authentication using that client. A good standard should block this all off at the source; it should (to borrow from the Chromium dev team) encourage developers to fall into a "pit of success."

We already ran into this problem with 2FA codes on mobile devices. How long did it take Google Authenticator to support backup? That has impacts on the ecosystem beyond just "is it possible for someone who knows about the issue in advance to choose a client that's more open?"

> There also hasn't been anyone yet who has tried to define what that interchange format should be.

Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?

I mean, they're the ones that want me to get rid of passwords. If they want me to adopt their solution, they need to have an interchange format. It's kind of their problem more than it's mine.

> Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.

Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.

Again, going back to this philosophy of the "pit of success" it should be harder to lock a customer out of backup than it is support portability. Portability should be the default, and it should be work to make that go away. And that's a key difference with passwords. It is work to make a password unportable.

----

At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.

I would be more amenable to these kinds of conversations about the challenges of supporting arbitrary sync/export/import if I didn't have to start each of these conversations by calling out that arbitrary sync/export/import doesn't already exist. Because you're right, there hasn't been anyone who "has tried to define what that interchange format should be." That interchange format doesn't exist right now.

I don't think it's accurate or helpful if someone asks, "is this portable yet" to say "yes" when there is no interchange format and 3rd-party sync is an entirely theoretical future capability that companies are looking into, and there's outright resistance to building 3rd-party sync into the spec. Give reasons why that portability doesn't exist yet, sure. Promise about what will exist in the future, sure. But don't just say, "yeah, we're portable, you can sync keys" when both Safari and Android have huge limitations on when and where keys can be synced.

> So what plans can you point me towards where Google/Apple is announcing that they're going to build a generic API for exporting passkeys from the phone? Do they have a timeline up?

I'm not privy to their priorities or timelines, no.

> And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.

But other companies with a history of being open here also do not have the feature yet. I am equally non-privy to their priorities or timelines.

If you want to say "passkey implementations do not have a bulk export/import feature, which makes it time consuming to switch between implementations", that is 100% factual.

I would not qualify this as a "lock-in", any more a phone that needs to get its software reinstalled is "bricked". And I wouldn't take current state to imply some inherent permanent ecosystem-wide rejection of user backups and data portability, when many vendors have implementations that are still in beta.

> My worry is that most of them won't, and that hardware attestation will get rid of the rest.

There is a great deal of worry about hardware attestation even by the vendors you are likely most concerned about. Apple for example not only removed their attestation, but now anonymizes the authenticator via a zeroed AAGUID.

No matter the vendor, their users (and the overall ecosystem) will suffer if relying parties build allow lists of acceptable authenticators, and deny all others.

That said, I do suspect the ultimate goal is to have sites be able to tell if an authenticator can allow them to shortcut additional authentication checks or not. It could be those websites give a more complicated authentication process to passkeys which do not meet their physical factor requirement.

>> There also hasn't been anyone yet who has tried to define what that interchange format should be.

> Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?

Putting aside that I can't speak as to whether there is or is not an effort underway there -

It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.

If passkey providers hypothetically want an interoperable interchange format or protocol, they can try to standardize it in a number of places including under FIDO Alliance. Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.

> Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.

I don't think this fixes your overall concern. There's no technical measure to prevent implementations from limiting backup/restore even if you make all authenticators anonymous.

Likewise, I don't believe websites would choose "friendly" credentials over "strong" ones. They would let the system survive or fail based on the user feedback/complaints of "strong" mode.

> At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.

Yes, the process is automated within the same ecosystem, and we (finally) have a way to use a phone to e.g. authenticate to a computer and cross ecosystems. So far there is no process to batch migrate.

There _is_ a manual process to migrate. I get your desires and your concerns about users not understanding that they will have this multi-device process for migration today. I'm personally hopeful that there will be a solution here eventually to streamline switching platforms and passkey managers, once someone prioritizes it.

> I'm personally hopeful that there will be a solution here eventually to streamline switching platforms and passkey managers, once someone prioritizes it.

This is hopelessly naive.

We need to be actively making a lot of noise and sabotaging industry efforts to use passkeys until the respective vendors solve data portability.

> > Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.

How would they? None of the software involved here is Open Source, I can't open a pull request for any of this. And the backup/restore isn't going to work with any of the major players.

It's kind of striking that there literally isn't an Open Source provider supported on any of the major platforms. Let's say you build an Open Source one for Linux. Is it usable with Chrome? No, Google has no plans to support that. Does Mozilla have a working implementation? Also no.

Is that the FIDO Alliance's problem? Sort of? I mean, they want me to believe this is an Open standard. How many "Open" standards have zero officially sanctioned Open implementations of the standard?

> It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.

The FIDO Alliance has more than two members. Microsoft/Apple/Google are already in talks about how to build out passkeys. And they're the players that really matter here. Whatever standard they come up with (or decide not to come up with) is going to dictate how the rest of the ecosystem moves.

But again, they're the companies trying to tell me this is an Open replacement for passwords. I feel like it's kind of on them and their alliance to prove it.

I'm with you, Dan. It is grossly irresponsible for the industry to be pushing passkeys while fundamental problems like transferring from one ecosystem to another aren't solved yet.

We need to hold their feet to the fire and actively push people away from using passkeys until this problem is solved.

> actively push people away from using passkeys until this problem is solved.

I guess this is where I'm arriving, too. Passkeys are a nice idea in theory, but the whole thing is too early in development to use or recommend to others at this point.