client certs can get generated hassle-free in the browser without user interaction:<p>http://stackoverflow.com/questions/9197484/generating-client-side-certificates-in-browser-and-signing-on-server<p>implementing this into an authenticator seems straight forward: generate client certs after first login and link it to a user's account. the next time that user visits the website the browser will automatically pick the right cert to authenticate itself. depending on the browser settings a confirmation dialog might pop up.<p>thinking even further the authenticator could also require the user to enter a password after manually logging out and accessing the site again. in that case i'm assuming that the user doesn't want other people using the same machine to be logged in automatically.<p>why do we still have to fill out login forms?
TLS client certificate authentication is technically quite good, better than anything else you have available in a browser.<p>Unfortunately:<p>* The UX for installing a certificate on a Windows or Mac machine is atrocious; it's incomprehensible even to people who understand X.509, and might as well not exist for laypersons.<p>* The browser UX for matching certificates to sites is not much better; the mechanism basically only works if you have a single client cert you use for every site.<p>* Getting certificates from a CA introduces yet another nearly incomprehensible UX element, and leaves your site to the mercy of the CAs you trust.<p>* Issuing your own certificates involves <i>you</i> building a hopefully- less- incomprehensible UX for getting certs into the hands of users, and also implicates a chicken/egg problem of figuring out when it's OK to issue a cert to whom.
What security does this provide that another token like a cookie does not?<p>Certificates provide value where you can independently attest that the client is who or what it appears to be.<p>Client certificates are the basis of MDM solutions, for example. In a corporate setting, I enroll my iPhone with the MDM, linking that device and phone number to my identity. The MDM solution issues certificates identifying my device and my identity to that device. That allows subsequent interactions with corporate systems to be authenticated.<p>If I drop the phone in the toilet, get a new one and restore it, I must re-enroll, as the phone serial number changed. The old certs are revoked. The key assumption is that the mobile device platform can be trusted to provide an accurate serial number, phone number, etc.<p>Browsers cannot be trusted much, if at all. A modestly clueful attacker can spoof all of the metadata provided to the website. I can take that client certificate and copy it to any other browser.
It's used extensively in finance from what I've seen. Not personal or even business banking, but trading, investment portfolio management, financial advisors, those sorts of area. Everyone is given a certificate they install, and that's to identify them.<p>I've also used it in client-server applications, not on the web, and it was very effective as a transport layer security mechanism, but in that case it was devices talking to devices in an automated way, so there was never a problem with user experience or education of users.