It certainly would make sense to improve the UX as opposed to coming up with different implementations.

webauthn basically forces use of HTTP as the application level protocol, whereas a client side TLS certificate will work regardless of which application protocol is in use.

Client certificates, as the name might hint, certify your identity. But a big thrust of technologies like U2F and WebAuthn was not to do that, for privacy reasons.

My FIDO authenticator has no idea who I am, no opinion who I am, so you can't use it to do identity correlation. It's only useful for the very specific problem we wanted to solve "Are you still you?" "Yes".

In contrast a client certificate for u801e is enduring proof you're u801e and signatures the client cert makes during login will be durable proof that u801e logged in. PornHub can show Facebook and GitHub that the same user is using their site. So that's a privacy hole you can drive a truck through.

There are numerous practical problems with trying to leverage TLS client certificates for this work, but that's a big privacy problem.

> In contrast a client certificate for u801e is enduring proof you're u801e and signatures the client cert makes during login will be durable proof that u801e logged in. PornHub can show Facebook and GitHub that the same user is using their site. So that's a privacy hole you can drive a truck through.

Client certificates can certainly be separated based on different domains. So, there would be no way to really determine my identity across multiple websites if I sent each one a different CSR and they each gave me different client certificates. The browser should only send the client side TLS certificate that's relevant to the server it's trying to connect to via TLS.

The main purpose of the client side TLS certificate is to verify the identity of the client on the server side, just as a server side TLS certificate signed by a trusted CA allows the client to verify the identity of the server. In the case of the client side TLS certificate, it doesn't have to be signed by an outside entity. There could be an internal CA the server uses to sign those CSRs and when the client connects, the server need only to verify that the client cert presented has a valid internal CA signature.

There's no reason why it has to be horrific. I'd like to see someone make a decent attempt at making client TLS certs actually work well, including not using the same cert for multiple domains by default. Other problem is, I don't think many web server frameworks have support for them either.