U2F does that. I wonder if sites could use the U2F token as the first factor and ask you to enter a password as the second factor (along with a "remember this computer" box for the password). Would make things much more convenient (unless you were on a device that didn't support U2F, I guess).

It also seems that would help with not giving out passwords to spoofing sites

The spoofing site could just pretend your U2F was valid and get your password, although it couldn't really do anything with it anyway.

The spoofing site wouldn't/shouldn't be able to pass the browser validation of the TLS server side certificate.

Why not? How hard is it to get a cert for a domain that looks like paypal-businesscenter.com?

Moreover, the browser could remember the expected shared secret based on its and the server's RSA exchange.

Sounds like a great solution - would browsers need to support it? Do you have any resources on implementing it?

Browsers has supported it since the late nineties. The problem are on the practical side. If you ever log in from more than one machine, all must have your private key, and the mechanism for synchronising keys between machines are not there. You have to manually install your key each place. It has also been too hard for most people to make and handle public/private key pairs. Also, if you don't have the private key with you, there is no way you can log in to the site. All of these problem and many other usability problems would have to be solved for client side certificates to be a success.

> If you ever log in from more than one machine, all must have your private key, and the mechanism for synchronising keys between machines are not there.

I don't think that's good practice. What's better is to have a separate key/certificate per device that's used to access a service. That way, even if one machine is compromised (or stolen), then the user can still use other devices to log in. Also, the service provider can disable certificate log in on a per device rather than a per account basis.

> Also, if you don't have the private key with you, there is no way you can log in to the site.

That's not necessarily true. Some HTTP server software (e.g., nginx) do have the option of requesting/asking for a TLS client certificate rather than requiring one. If one is not provided, then it's still possible to connect and log in. Server side policy can be much more strict in terms of locking the account in case of incorrect credentials or restricting access to certain account features if the client certificate wasn't provided.

Chrome already syncs data between platforms. Seems reasonably straightforward to include client certs in that data.

Already supported by browsers. Massive PITA to use. The old Startcom SSL webapp was an example.

Private keys and certs aren't as portable as passwords. Backing them up, copying them to another device, etc. lacks good UI.

This is how web auth was supposed to work. It turned out to be too hard to deploy outside of enterprises.

U2F is the modern re-do of client certs.