Yes, the author clearly has, because he talks about it in his conclusions. The exercise, then, is one of re-discovering why things are the way they are.
So why are people trying to replace the algorithm, when what we need to do is to replace the UX? Patches could be submitted for both Chromium and Firefox to give them a better client-cert flow, but I don't see anyone working on the problem; just a constant parade of restyling on tab-strip and toolbar and notification banner UX.
I mean, ideally, a client cert would be treated pretty much exactly like a cookie: generated on first connection to a website and automatically stored by the client; synced across browsers; etc.
And, I mean, you could treat a client cert like a permanently logged-in account credential, but it'd be much better to just treat it as essentially an unforgeable browser fingerprint+session ID: something that just "pairs" the client and the server, but where you still have to log in after that pairing process, but only once. (As long as the cert gets synced to another browser, that browser is now logged into the site, because it's now sending the fingerprint of a "session" that's logged into the site.)
With such a setup, you would be able to just "clear" the client cert (like a cookie) to log out, and then get issued a new one and log in again on that one, if you wanted. You wouldn't have to worry about losing your cert. You'd be able to have multiple devices with multiple client certs that are each separately logged into the same account, if you wanted. But, since each client cert would be associated with an account, and vice-versa, you'd be able to revoke a client cert's access to a particular account: to, effectively, log another device out remotely.
The nice thing about this workflow, actually, is that each and every HTTPS site could always issue each visitor a client cert, just as we currently generate server-side session IDs for each visitor. It'd become a best practice to have client cert issuance on by default at the load-balancer level, like HSTS is now. (And load balancers can just translate client certs into a plaintext "browser fingerprint hash" HTTP header, that can be detected by anything further along the request chain that currently knows how to deal with cookie or URL session IDs.)
Because HTTP is stateless and session-less, and cookies are a hack to make it stateful. We introduced the notion of a session where we already had one, in the form of TLS sessions.
Note that it would also make APIs much simpler by moving the authentification, authorization and session logic in the certificate, where it actually already is.
> We introduced the notion of a session where we already had one, in the form of TLS sessions.
But that would only apply to HTTPS. An extension to HTTP itself was necessary so state could be maintained for both HTTP and HTTPS. Especially in the mid-1990s (the era when cookies and HTTPS were introduced) when acquiring a CA-signed certificate was cumbersome and expensive.
That is true, but I'm one of those guys who believe HTTP-only should die.
Even without going as far as that, I believe that as soon as you have to manage some kind of session you're going to have private data flying around, and that should be protected in TLS.
A correctly done client cert provides mutual authentication (the server's ssl cert and priv key it had when you signed up with it is the one needed to sign in in the future).
Somehow I don't qualify a misplaced apostrophe (either by human error or bad autocorrect) on the same scale as choosing a fundamentally bad database or failing to understand/take advantage of powerful technologies such as client side certificates.
We use client certs in the company where I work to authenticate into all internal pages. Once the infrastructure was in place (an easy way to generate a certificate to any new colleague) it has been a breeze to setup and use.
Server side, it is 3 or 4 Nginx lines. Client side, people only have to get the cert, click it to open, and install it on Chrome. After that, they are happy they don't have to remember any password for our different services.
I think we could implement it for our users if we gave the option to "login using cert" and "send me a new cert" (to the email they used for signin). People need minimal training but they don't have to be computer literate to do it (half of our company are not, and they found it better than passwords once the system was in place).
Have you ever heard of TLS and client certificates? Every browser and every decent web server supports TLS with a client certificate for auth.