There are several problems with TLS Client Authentication, which have impeded its adoption across the Web:

Obtaining a certificate usually requires interaction with a Certification Authority (CA), with a lengthy process for identifying the user, setting up an account with the CA, and at the very least dealing with the UI presented by the <keygen> tag. Most non-technical users don't understand the trust model behind CAs, and don't want to be bothered with questions about RSA key lenghts, etc.

Once the certificate is obtained, using it presents further UI complications: Since the certificate is needed during the TLS handshake, the user has to approve its use before they can interact with the website. If using a certificate equals "logging in" to a website, this means that a user can't really interact with a website requiring certificates in a "logged-out" state. At the very bottom of this page, for example, you can see a "Sign in" link that allows authorized users, once signed in, to edit this page. With TLS Client Authentication, we can't really build a similar experience - the user has to decide whether they want to be logged in before they first interact with the page.

Another example is multi-login. Google, for example, allows multiple users to be logged into the same HTTP session. Today, Google uses this feature mostly to show users a little "fast account switching" widget at the top right of the page, but it's easy to imagine that some products like Calendar or Docs show an aggregate view of the data belonging to all logged-in accounts. TLS Client Authentication doesn't allow this use case, either.

Once a user has obtained a certificate, any site on the web can request TLS Client Authentication with that certificate. The user can now choose to not be logged in at all, or use the same identity at the new site that they use with other sites on the web. That is a poor choice. Creating different certificates for different sites makes the user experience worse: Now the user is presented with a list of certificates every time they visit a web site requiring TLS Client Authentication.

Since certificates ideally are related to a private key that can't be extracted from the underlying platform, by definition, they can't be moved from one device to another. So any solution that involves TLS Client Authentication also has to address and solve the user credential portability problem. Potential solutions include re-obtaining certificates from the CA for different devices, extracting private keys (against best security practices) and copying them from one device to another, or cross-certifying certificates from different devices. So far we have not been able to come up with good user interfaces for any of these solutions. 

Large datacenters often terminate TLS connections at the datacenter boundary, perhaps even using specialized hardware for this relatively expensive part of the connection setup between client and server. If the TLS Client certificate is what authenticates the user, then the authenticity of that authentication is lost at the datacenter boundary:

This means that the TLS terminators become part of the trusted computing base - they simply report to the backends who the user is that was authenticated during the TLS handshake. A compromised TLS terminator would in this case essentially become "root" with respect to the applications running in the datacenter. 

Contrast this with a cookie-based authentication system, in which the TLS terminator forwards the cookie that the browser sends to the app frontend. In such a system, the cookies are minted and authenticated by the app frontend, and the TLS terminator would not be able to fabricate arbitrary authentic cookies.

TLS Client Authentication, in its current form, cannot be used to authenticate users on the web. Reasons range from privacy issues to usability issues to practical problems with the way large datacenters tend to be set up. 

Instead, we propose to use Token Binding to authenticate TLS clients and to channel-bind HTTP cookies to TLS channels.