I keep asking what advantages passkeys offer over TLS self-signed client certificates. I haven't got any answers so far. Perhaps increase the security by encrypting the private key with a password or an external token. This is safe, like SSH and unlike regular passwords, because no secrets are sent to the server. TLS certs and (encrypted) keys are more tangible and easier to manage.
Perhaps passkeys do offer some advantages over TLS certs. But can't those be added to TLS, rather than rollout an entirely new system? The infuriating part is that this facility exists in browsers. They just let it rot to an extend that it's practically unusable. Meanwhile, Gemini browsers are using it quite successfully (for those who use Gemini).
Their only difference is the automated provisioning.
So they took something that works well and created a bad UX around it, while ignoring the working, yet languishing UI/UX that was already around?
Despite all their faults, for the average user, Passkeys are still miles ahead of GnuPG card, PIV, PKCS#15 etc.
Gemini strives to finish an entire request in a single transaction. So TLS certs are really the only option for authentication. That's how I learned the elegance of TLS client authentication workflow and started asking why this is so neglected in web browsers.
Not everybody trusts whatever first hop terminates TLS to also do authentication, and it completely falls flat at non-repudiation for transaction approval.
Despite all their faults, for the average user, Passkeys are still leagues ahead of GnuPG card, PIV, PKCS#15 etc.
If you try to describe how you _want_ the TLS client certificate UI to work, you'll end up with passkeys.
It's funny, we used to have a html tag that would exactly that: <keygen />