This scheme is not, absolutely not, a substitute for the entire range of authentication schemes. It’s target is those systems, that are currently using things like capcha, openid, or typekey. I should have made that clearer.

The third party trust issue appears in all auth systems, even PGP. At these system tend to condense to a single auth vendor exist in all these systems. Nothing in this proposal works on that problem. That’s a bummer. It may even tend to encourage that; more of a bummer. Guilty as charged. But this system has the positive that very little is actually revealed to the center; only that you visited a sign up page.

The critique that the third party is learning your network of relationships is bogus. All the parties enumerated above are learning that. You bank, your credit card, your email provider, your isp, your mail carrier, etc. etc. etc. All these can observe you and distill out your relationship network. The small amount of additional revealing here is not adding to that problem. That problem is regulatory. The only technical aspect to that problem is that systems, like this one, should be fastidious about not revealing more than is absolutely necessary to do the job and then more so they should not encourage additonal revealing. This design succeeds on both those. Where as systems like DoubleClick, OpenID, typekey, etc. all fail that test. PGP fails that test because it encourages the revealing of a universal identifier.

The loss of valuable marketing info is a barrier to adoption by the sites that care about building deep rich models of their users. The counter point is that this lowers the barrier to signing up users a lot because users don’t need to reveal anything other than that they are known to the trusted third party. The hope is that this system solves a very large class, possibly the largest class, of auth problems for sites. I.e. all they want is to be sure that this new account is not a spammer, that he’s a real person, with an existing relationship with somebody that means we can trust him not to act like a complete bozo. One of my caononical use cases is wiki edits and blog comments; I believe that if you can solve the auth problem for those while allowing users to remain anonymous you’ve covered a huge subset of the real world authentication needs. If you can do that you relieve a lot of the presure to create more invasive systems.

PGP, an all the other private/public key solutions are not going to happen. There require changing the client side software and that installed base is hard to move and it’s controled by actors who are proven to be untrustworthy. it requires significant innovation to solve the usablity problems. It requires sophisticated advances in the current state of the art to address technical issues – like the encouraging of a universal ID. These, and others, are barriers to it being deployed. None insurmoutable but in total sufficent to make it a very unlikely final state for a very long time to come.

you also lose a lot of valuable (for marketing) info about the user if you don’t get his address, age, salary info. and a lot of web sites rely on this to get a higher CPM rate for their ads. yes advertising is evil, but it pays the bills for a lot of sites.

What I would love to see if some kind of GPG based authentication scheme being used. .. where the browser ‘knows’ your private key and can encrypt a message knowing the servers private key. (which are stored on 3rd party servers). you establish trust by referreal. A knows B who knows C and B thinks C is ok, so A should.
depending on the level of trust given different details about ‘A’ would be diviulged.

Yes the opaque token could be trouble.

But first notice that the cell phone, bank, email example all have a similar feature that the cell phone company, the bank, and the email provider are all able to collect a model of who you have relationships with. The only way to have third party help with authentication and avoid that problem is if the 3rd party issues some document you can present to, like a passport (sic.), and the site that’s curious about you can do some sort of proof on. Let’s set that aside.

Notice that the sites don’t need to reveal anything to the ‘trust site’ after they set up their own account. They have don’t have any reason to display the web bug, for example, so the trust site won’t get fine grain tracking info. The only data the trust site accumulates is from the presentation of the web bugs and the explicit moments when the user asks to be vouched for. It can be as little as that.

Meanwhile I’m quite pleased how little data the visited sites are accumulating The total data in that account might be as little as: user_name, password, and the opaque_id. A really lite weight site could encrypt that an store it in the user’s cookies.

Why keep the opaque_id? Well because you could use it to report back bad actors. You might also use it to forward messages to the user, since you don’t even have his email address!

This approaches solves the problem of two sites sharing information about a user. They can’t because they don’t have a common handle.
But it doesn’t solve the problem of the third party (authentication service) being able to stick its nose in the middle, because IT is able to connect these handles back to a single account reference and is still partly an owner of the customer relationship.

We found this blog entry very interesting so we’ve added a Trackback to it on our site.