Yubikeys have a single master private key, and derive site-specific keys from that. It makes sense in this model not to allow key export. On the other hand, if you have 100 sites you log in to, you can use one key for everything. If you get a new computer, you can just carry on using the same key. If you lose or damage your key, admittedly things get harder.
Passkeys are defined by at least one authority as "resident keys" in the sense that you have one key stored for each site. If you have more than one computer, or your old one breaks and you buy a new computer, you somehow have to get your 100 keys from A to B (and possibly keep them in sync). You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place.
Even enterprise HSMs can do this to some extent with key-wrapping. (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.)
Personally, the way I'd like key-based authentication to work is something like how SSH keys work currently, where people who know what they're doing can set things up in a way that works efficiently for them. You can choose yourself whether you want 1:n or m:1 or m:n relationships between your keys and your sites and how to manage them.
Because the audience for passkeys is non-technical we are ending up with paternalistic user-hostile implementations that make all the problems the user's.
I don't want to be locked into a platform. I don't want to have to shoulder the burden of making sure I enroll new hardware tokens every few years because I can't just backup / restore the key material in a sensible manner. I don't want one more thing to worry about or pay somebody else for.
I have been using a password manager since 2002. I intend to keep using some kind of password management (password vault, tokens, passkeys, etc) for the rest of my life. I'm worried that the ergonomics of passkeys are very bad and not well thought-out for the long term.
I'm worried the market is skewing in that direction and I will be forced into passkeys and away from passwords to retain access to basic services. I don't really want to be a vassal of a feudal platform lord for my personal password management needs.
Having said all that, you said:
> If you lose or damage your key, admittedly things get harder.
That's worrisome to me. I think the implementers are thinking about it from an "if things go wrong" perspective. I come at things from a "let's have contingencies for when things go wrong".
For what passkeys do I think end users are ill served by the default mode being either user-hostile or feudal.
> Even enterprise HSMs can do this to some extent with key-wrapping.
This. I feel like passkeys are taking the lifecycle model kinds of questions that HSM buyers have to make and thrusting them upon non-technical end users.
Businesses might purchase an HSM with key-wrapped export or backup functionality because they need fault tolerance, disaster recover, and support for key lifetimes that exceed individual hardware component lifetimes. End users don't seem to be getting this choice with passkeys.
It feels like the people implementing passkeys haven't thought about handling those kinds of considerations in a way that provides convenience and security to end users. The answers I see all amount to "Enroll multiple keys for each site. Handle it yourself manually. End users are too stupid to be trusted to handle this well. Tough luck for you if you don't like this beautiful garden we've built for you."
If you're already a password manager user, then it sounds like your gripe is "my password manager doesn't support passkeys." That seems either a short-term issue that would be resolved in time, or you need to find a more powerful manager. It seems the browsers allow passkey providers to be pluggable already, as several third-party vaults support passkeys.
So I see your concern as more "I need to find a password/passkey manager that fits my desires" and less "passkeys require being locked into a platform."
I worry that people who think device attestation and not being able to backup passkey data being good things are too close to the driver's seat when it comes to the direction of passkeys. I see a possible future where free and open source passkey implementations won't be usable because relying parties will want to see device attestation.
I would love to use a hardware device in lieu of a password manager. I just need a tolerable backup/restore scenario.
Apple is playing consumer advocate here by refusing to support device attestation keys on consumer hardware. With the large market share of the iPhone that's a key wedge that should keep things relatively open on the consumer side, presuming Apple sticks to their ideals here. The biggest advocates for device attestation are doing so for corporate "enterprise environments" and that will likely be a dividing line that corporate networks may require device attestation and consumer devices and applications won't/can't.
With U2F it was hard to track which sites used the key. If I wanted to move to a different physical key, what sites should I update to not need to worry about arbitrary account recovery processes? This is one of many reasons I hate SMS verification and why I didn't use U2F beyond a few high-value sites. But with resident keys there is a list of sites I can walk through to migrate or to keep "in sync" with a spare key. Just like with passwords and OTP. Needing to sync them is an existing problem with passwords and OTP; I'd consider it solved, but even if you don't, I don't see why that's suddenly "consumer-unfriendly."
For the service lock-in concern, the resident aspect makes it easier to migrate. Yes, there might be a way to make it easier still, but when the alternative is a physical key it seems a strange demand. I'm the sort of user that'd use a physical key, though, even if the number of available resident key slots is low at the moment.
(If a site doesn't support more than one passkey, then I wouldn't use passkeys on the site.)
> You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place.
I get this, but I think it needs to be acknowledged that export presents a risk and that needs to be balanced. We might disagree with each other on which is more important, but I can certainly see a perspective that disallowing export (for a specific implementation) is more important than convenience.
I'm also not sure to what extent the spec / implementers need to provide functionality to work around the fact that some sites are not implementing passkeys properly. That feels a bit icky.
>> I get this, but I think it needs to be acknowledged that export presents a risk and that needs to be balanced.
I see it from the other perspective--not allowing key export is a risk since the user does not have full control of their key and cannot fully manage how it is used.
It is a key and needs to be protected, but not allowing key export / import disrespects the user's choice and freedom and is a perfect recipe for vendor lock-in.
What is the ideal balance between protecting the key and respecting the user's choice and freedom?
> What is the ideal balance between protecting the key and respecting the user's choice and freedom?
There's no right answer to this. The eternal struggle of mankind is living with the fact that other people have different value systems and therefore end up making decisions that are consistent with their values but that someone else disagrees with.
This is the classic "do you give the user enough rope to shoot themselves in the foot with?" dilemma. Not being able to do what you want with a key that belongs to you? Bad. Having your key stolen because the systems that look after it explicitly let it be exported? Also bad!
Passkeys are defined by at least one authority as "resident keys" in the sense that you have one key stored for each site. If you have more than one computer, or your old one breaks and you buy a new computer, you somehow have to get your 100 keys from A to B (and possibly keep them in sync). You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place.
Even enterprise HSMs can do this to some extent with key-wrapping. (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.)
Personally, the way I'd like key-based authentication to work is something like how SSH keys work currently, where people who know what they're doing can set things up in a way that works efficiently for them. You can choose yourself whether you want 1:n or m:1 or m:n relationships between your keys and your sites and how to manage them.