Risk of lock-in from export blocking

[EtiennePerot]

As a Passkey user, I am concerned about the potential for vendor lock-in of my credentials.

Specifically, I want to ensure that my credentials can be exported without relying on my current credential provider's willingness to permit the export at the time I want to do it. The current CXP spec appears to allow providers to block (or selectively approve) export requests.

Here's a hypothetical scenario that could unfold with the current version of the CXP protocol as I understand it:

• I decide to use provider FOO as my CXP-supporting credentials provider.
• FOO provides a great service and over the years, I store more and more of my credentials in it.
• Somewhere down the line, FOO realizes that they can make more money by raising their prices, so they do.
• People use CXP to switch to provider BAR en masse, which offers similar services at lower prices.
• FOO notices this opportunity and adjusts their exporter server's logic to deny requests from BAR, or to deny export requests for users like me who they have determined to be capturable users.
• I am now an unhappy user with my credentials stuck in FOO that I need to keep paying in order to not lose them.

Alternative scenarios include the cases where FOO introduces a bug in its exporter logic, or is legally compelled to block all exports by its local jurisdiction, etc. In either way, this causes innocent users' credentials to be left stranded.

This seems like a scenario that CXP should aim to prevent if Passkeys are meant to replace passwords, as passwords do prevent this scenario. I would refer to this property as being "permissionlessly exportable", i.e. it is possible for a user to export their credentials to another provider without needing to make trust assumptions on the provider where the credentials are stored.

How can this be solved? I can think of a few solutions here, but would first like to ensure that there is agreement that having permissionless exportability should be in scope for CXP. Let me know what you think.

[HansReich]

Hi @EtiennePerot , I just noticed this issue never got a public response so wanted to chime in. Your concern is very much heard and appreciated and has generated much discussion inside the Alliance.

[victorb]

@HansReich would it be possible to share what the average/typical position ends up being inside the Alliance, between yay and nay?

[HansReich]

The general vibe is supportive and language has been added to this effect, though it looks like we haven't done a public working draft in some time so I don't think that's externally visible yet. Also usual caveats about in-progress work subject to change.

[tomchiverton]

Isn't it this the case with any 3rd party, for any login method?
Firefox, could be malice or accident, prevent you exporting or viewing usernames and passwords, same as with any Passkey it holds.

We should close this as not in scope, there fore.

[EtiennePerot]

@tomchiverton Firefox is local, open-source software. If some update or bug prevented it from exporting credentials, users can install an older version, or inspect and edit the code to fix the bug, and run it on their own computer. Non-technical users can rely on technical users' efforts to help them out in such a situation too. All of this is possible without permission needed from Mozilla. This lack of permission is why such a requirement isn't needed for Firefox and such browser-based password managers.

In the case of credentials in scope for CXP, this includes credentials stored on secure hardware elements which inherently require the permission of their manufacturer and/or operator to extract data out of them.

I think a closer analogy is that of the domain name system (DNS). When you register a domain name, you rely on the services of a registrar which holds the domain for you. You are comfortable doing this because, should this registrar turn evil or raise their prices beyond what you can afford, you are confident that you can export your domain to another domain name registrar later. Financial incentives would compel registrars to block such exports, which is why there is a need to have an enforcing mechanism (ICANN) that ensures that registrars cannot lock in their users.

[tomchiverton]

Riighht... But if you choose to use a (hardware or software) token that you dont control, again, that's on you, not the standard.
Unless FIDO is really going to require no-name hardware companies shipping theae things to make their full hardware and software specs open source Just In Case...

[rektide]

In general it seems like such a huge disadvantage that the flow uses a Credential Exchange Protocol, since this gives Exporters some ability to control who they will or wont send data too, to modify their behavior adversarially.

If users could export to a file, they could be secure knowing they held a viable copy of the Passkeys/credentials that the current managing/exporting party couldn't rug-pull out from under them. I tend to dislike the notion of the Credential Exchange Protocol, as it feels inherently untrustable by users: won't be there when you need it. This issue shows the conflict, of being dependent upon the credential manager/exporters, and how it's not good enough for users.