First, it's awesome that this rather important subject is getting attention, and kudos to Jen for giving it thought and providing a perspective [1].
Logging adds value once an account is compromised, so is a contingency measure (minimising impact). Solving this problem requires mitigation (minimising probability) as well as contingency.
Many comments here suggest the use of PKI. PKI is part of a solution and, as with logging and audits, requires more.
PKI's biggest problem is that it doesn't scale. The question then becomes one of issuance. Self-issued certificates have no credibility so cannot be trusted. That problem is solved by using a certificate authority that can be trusted.
That leads to the next question, which is whom to appoint as a certificate authority (CA)? This thing [2] should scale, so my certificate must work world-wide, with any web site and, while we're at it, offline in meat space.
That makes canidates like my bank or a credit check agency bad choices, because they haven't the reach. Credit card companies like Visa, AMEX or Mastercard have better reach, but that only accounts for a tiny percentage of the world's population, because it excludes the poor.
The only viable choice then becomes the organisation that already deals in identity - government departments that issue passports, ID cards and driving licences.
Of course that's just national. The solution to that problem is to federate identities between governments. Awesome. First part of the problem solved [3].
The next part of the problem is anonymity, and it's various variations. This can be solved by using a privacy-enhancing credential - a problem that was solved by Stefan Brands at Credentica [4].
The tradgedy is that while these solutions exist, are mature and proven, there is just not enough incentive to make them a reality.
Some closing notes: Any good identity system must adhere to all the laws of identity (http://www.identityblog.com/?p=352/#lawsofiden_topic3). Technologies like OpenId, Persona and OAuth don't even come close. SAML and WS-Federation do a much better job of it, but both SOAP/XML-based. Which makes them unpalatable to many. There's an oppotunity in there somewhere...
[1] Logging has been done - just not at the scale Jens envisions. Many military and intelligence systems inform the user of previous acvitivy on login. The better ones use geolocation to tell the user where the most recent logins occured.
[2] "This thing" is really an identity meta system.
[3] This technology exists in the form of WS-Federation and, to a lesser extent, SAML (which relies on the browser, so doesn't work at the service level).
[4] Stefan Brands came up with U-Prove, which was open-sourced by Microsoft after they aquired the technology. IBM have also come up with a privacy-enhancing technology (PET) called idemix (identity mixer). An important attribute of any self-respecting PET is that it must be claims-based, so that it functions in a world of federated identities.
Isn't the issue with PKI the 'I', rather than the PK?
In the case of replacing passwords at a website, the issue of 'credibility' or 'trust' is irrelevant - you have no trust or credibility with a u/p, so why do you need that with a PK?
If I'm just replacing user/pass with a PK, why do I need a CA and all the infrastructure around that? The goal is to put something serverside that cannot be used against me elsewhere - a 'public' token that lets us communicate in secret.
The only concern is one of tampering, which would be a problem in either direction anyway.
Mostly because you need the "I". Unless you start accumulating PKs as we do passwords. Some sites will require access revocation, others not. Some require known identities, others not. Unless an identity system is ubiquitous it won't gain widespread adotpion. For it to be adopted it needs to address every scenario that an identity meta system faces.
Why can't I just use the same PK everywhere? The whole point is it's not reversible to the Private key.
Nothing else about how passwords are handled would have to change.
Public key auth works pretty okay for ssh with a single keypair. I don't see why it wouldn't work for websites too. (As count also mentions) the entire point is that you can prove your identity without giving the entity you're proving to the ability to do the same.
The only viable choice then becomes the organisation that already deals in identity - government departments that issue passports, ID cards and driving licences.
What could possibly go wrong? There's a reason why it's unconstitutional in my country for the state to issue a single ID number to every citizen.
A protocol should let anyone be a CA, and it should be up to each party to choose what CAs it accepts. If some service wants to only allow government-issued IDs, that's fine, but there's no good reason to enforce that at the system level.
In fact, the article you linked puts it well:
But in many cultures, employers and employees would not feel comfortable using government identifiers to log in at work. A government identifier might be used to convey taxation information; it might even be required when a person is first offered employment. But the context of employment is sufficiently autonomous that it warrants its own identity, free from daily observation via a government-run technology. (...) So when it comes to digital identity, it is not only a matter of having identity providers run by different parties (including individuals themselves), but of having identity systems that offer different (and potentially contradictory) features.
Technology like U-Prove addresses exactly that scenario. Using it you could prove to a third party, using a government-issued credential, that you're over 18. You wouldn't disclose anything else. The third party couldn't derive you gov. Id, and the government couldn't prove whom you provided your credential to - even if the two collude.
"Self-issued certificates have no credibility so cannot be trusted"
How is that? I see the process working like this:
* I sign up for an email account by sending a request with a username and a public key. No need to "trust" the key, because this is an identity creation process.
* My bank issues a smartcard when I create my account, which can be used to log in to their website.
Sure, there are problems -- key revocation and dealing with lost secret keys are probably the biggest. Those problems are shared by passwords. The point is to solve the more glaring problems we have with passwords, like the fact that you need to rely on many different websites to manage passwords securely, or the fact that humans are terrible at picking passwords.
"The tradgedy is that while these solutions exist, are mature and proven, there is just not enough incentive to make them a reality."
Bingo. That's the real issue, and it always has been.
Logging adds value once an account is compromised, so is a contingency measure (minimising impact). Solving this problem requires mitigation (minimising probability) as well as contingency.
Many comments here suggest the use of PKI. PKI is part of a solution and, as with logging and audits, requires more.
PKI's biggest problem is that it doesn't scale. The question then becomes one of issuance. Self-issued certificates have no credibility so cannot be trusted. That problem is solved by using a certificate authority that can be trusted.
That leads to the next question, which is whom to appoint as a certificate authority (CA)? This thing [2] should scale, so my certificate must work world-wide, with any web site and, while we're at it, offline in meat space.
That makes canidates like my bank or a credit check agency bad choices, because they haven't the reach. Credit card companies like Visa, AMEX or Mastercard have better reach, but that only accounts for a tiny percentage of the world's population, because it excludes the poor.
The only viable choice then becomes the organisation that already deals in identity - government departments that issue passports, ID cards and driving licences.
Of course that's just national. The solution to that problem is to federate identities between governments. Awesome. First part of the problem solved [3].
The next part of the problem is anonymity, and it's various variations. This can be solved by using a privacy-enhancing credential - a problem that was solved by Stefan Brands at Credentica [4].
The tradgedy is that while these solutions exist, are mature and proven, there is just not enough incentive to make them a reality.
Some closing notes: Any good identity system must adhere to all the laws of identity (http://www.identityblog.com/?p=352/#lawsofiden_topic3). Technologies like OpenId, Persona and OAuth don't even come close. SAML and WS-Federation do a much better job of it, but both SOAP/XML-based. Which makes them unpalatable to many. There's an oppotunity in there somewhere...
[1] Logging has been done - just not at the scale Jens envisions. Many military and intelligence systems inform the user of previous acvitivy on login. The better ones use geolocation to tell the user where the most recent logins occured.
[2] "This thing" is really an identity meta system.
[3] This technology exists in the form of WS-Federation and, to a lesser extent, SAML (which relies on the browser, so doesn't work at the service level).
[4] Stefan Brands came up with U-Prove, which was open-sourced by Microsoft after they aquired the technology. IBM have also come up with a privacy-enhancing technology (PET) called idemix (identity mixer). An important attribute of any self-respecting PET is that it must be claims-based, so that it functions in a world of federated identities.