Their spec doesn't dictate that you shouldn't be able to see it. It's just dumb implementations that do it (mostly for lock-in purposes). There are ones where you can see it just fine.
It's not for lock in, it's for anti phishing purposes. Passkey managers are designed so that grandma on the phone to a scammer can't physically dump and email her entire passkey vault. It's impossible to get phished by a fake login page with Passkeys and it's impossible to send your private keys to someone on the mainstream Passkey managers.
Portability between Passkey managers is still an issue though. Last I checked there were in draft specs for migrating between managers but nothing ready yet.
Not being able to see it all can't be justified with "for phishing purposes". You can put a big warning there that exposing your private key is a risk, but user should be able to see it with needed effort. Not being able to see it at all is a problem, like anything that moves away control from the user to some external entity.
Of course they'll happily justify it with security reasons, but that doesn't remove the problem.
The person on the phone will just instruct grandma to ignore the warning and that it's important she continue and send the private key over to secure her account.
Considering there isn't really anything you can do with the private key other than logging in to a website, making phishing impossible is a higher priority than letting people view the keys. There are alternative open source passkey managers which do let you view them. But it seems pretty obvious the average person is much better off not having this.
The person on the phone will walk grandma through installing remote desktop, make gradma login to the account, show a fake Windows update picture fullscreen, and do whatever they like.
It's not reasonable to remove all agency from users because they sometimes click through warnings. Scammers will do the exact same refund scam script that they do today, and at no point will a passkey stop someone from doing a sketchy money transfer, or letting the scammer control their computer.
It just doesn't make sense to impose these extreme restrictions on exporting passkeys that won't stop the most common phone scams sctipts at all.
Well, I'm talking about definition of the spec and principle here. If they start dictating impossibility of looking at your own private keys by design of the spec, it should be strongly pushed back against. There is enough of abuse in taking away control from the user with all kind of opaque stuff.
And what you can do or want to do with your private key is really up to you. Copy it and import into another password manager could be a reasonable use case, besides simple curiosity. Basically, slapping on it some kind of DRM-like restrictions in the name of security isn't right.
You can make it non trivial to make it more clear that it has risks, but not prevent users from accessing it if they insist.
So there is a portability spec in progress for copying your passkeys between password managers, it's just seemingly not ready yet.
You can also use KeepassX which lets you export the keys in plain text which would be the power user option. Passkeys as a tech doesn't stop you doing this, only the mainstream Passkey managers.
> I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
Or in less patronizing terms: "do what we want or we're blacklisting you."
keepassxc is good, yeah. The point I'm making is that it shouldn't become mandatory to always force this DRM stuff. So far it didn't happen, but it always can.
They're probably just trying to not get their implementation blackballed with the attestation feature like one of the FIDO devs immediately threatened to do to keepass: https://github.com/keepassxreboot/keepassxc/issues/10407
I think the dance is all for naught though, they'll end up locked out as non-standard once uptake is high enough IMO.
