This is a long rambling post about an authentication trick I’ve not observed used in the wild. But it’s analagous to two tricks often observed in the wild. This trick is a way to do authentication. It is a hybrid of the web bugs, used by firms to build models of user behavior, and the trick of creating personalized Ads. Like Amazon does for it’s donation buttons.
Here’s the scheme. All authentication schemes sooner or later work by having some third party vouch for the user. At that point there are always, at least, three parties in the game. The user who wishes to be authenticated. The site that wants to get to know him. And finally the third party that already knows the user and who the curious site also trusts.
Lots of third parties get used for this. Paypal has a trick where they satisfy their curiosity by depositing some pennies into your bank account and then you prove that it’s your account by telling them how many pennies they deposited. They also get you to reveal your bank account data as a bonus.
Google recently adopted the trick of sending a SMS message to your cell phone. As an added bonus they get you to reveal you cell phone #.
The most typical technique is to have you reveal your email address and then the curious site sends you an email and you prove that is in fact your email address.
The bank, the cell phone company, the email address provider are filling the role of third party that can vouch for you. Of course these are more or less trustworthy. Any third party with a ongoing relationship might fill this role. You library, you government, your ISP, Amazon, Yahoo, Google, your OS vendor.
So here’s the trick. Any of these could offer a service to curious sites. When you go to set up a new account the curious site could place a web bug or larger image on account set up page.
The trick involves what we put into that image. What if we put a one time pin into that image? The user then copies the pin from the image into the account sign up page. The site he’s signing up with then takes that data and queries the 3rd party site to setup the account.
Of course a firm like DoubleClick can offer fraud protection services without the bother of getting permission from the user, and they could use web bugs to do that. But the key thing here is that the user is explicitly in the loop, he is implicitly granting permission for the trusted third party to help with authenticating him as he sets up the account.
Notice one key thing. While in the examples above the users bank account, cell phone #, or email address was revealed to the curious site. In fact the higher the level of trust the 3rd party enjoys the more serious the bit of information revealed. This scheme breaks that pattern. The 3rd party doesn’t need to reveal anything beyond the fact that they know the user. They don’t have to give up any account data. The user can remain pretty close to anonymous. Of course if more information needs to be revealed that can be arranged.
This scheme is slightly analagous to OpenID. In that system users are prompted by the curious site for their OpenID url. The site then uses that to fetch a page of info about them, and on that page is a pointer to a 3rd party that can vouch for them (well vouch that they control the page in quesiton). But actually this is quite different because the OpenID design forces the user to reveal a universal identifier, i.e. his OpenID url. While this system requires only that the user admit he has a relationship with the the trusted third party.
This is also analagous to the common scarab systems where a site places a branded scarab on their page and the user is encouraged to click on it to authenticate. These scarabs don’t need to be web bugs and usually aren’t. So unlike the Amazon donation scheme only the third party’s brand appear on them and nothing showing how the third party recognizes this users.
Scarab schemes didn’t gain traction in the market. The curious sites hated them because the threatened their customer relationships. The scarab vendors, like Passport, looked like they would stick their nose into the middle of the relationship. One term used for that entanglement is “account linking” the authentication site and the curious site both have account relationships with the user and part of the design for most of these systems involved linking these accounts. Another way to describe the fear that the scarab vendors would intrude on the the relationship of the curious sites is to say that they feared that one account would become subordinate to the other one. For example that before the user could get to his eBay account he would need to pass thru his dominate Passport acount.
The scheme outline here involves no account linking at all. The in this scheme the trusted third party X is only providing a single service – a means for the user to prove to the curious site that he has a relationship with X. That’s it. That’s less likely to threaten the curious sites.
The point of all that is that we reduce the threat to the user and the curious site.
This is also analagous to the capcha schemes. They present a puzzle to the user that by solving increases the site’s confidence that the user is a human. In this case we are asking the user to prove he has a sufficently high quality relationship with a third party site. Since such relationships are, presumably, difficult to obtain – i.e. they take time.
While there are two things I like about this scheme – very little is revealed about the user and no long term account linking is done – it is tempting to do a modicum of durable linking.
After the user enters the pin presented to him the curious site then queries the trusted site to see if that pin is valid. The trusted site can reply yes, no, or it might send back something more complex. Anything more complex implies either more revealing or more linking.
If the third party site hands back a token representing the user that allows further transactions about that user. For example if the curious site uses this to prevent spam his blog that token could be used later to report a spam event back to the trust site. that seems like a fine use. Of course it could also be used to send back more private or slanderous info about the user.
Tokens like the one in that example are common in account linking designs. They denote the linking.
Meanwhile if you suffered thru this entire thing I’m amazed! But here’s an amusing variation on this idea. How about a scheme were you can only comment on a blog if you make a small donation to one of the set of charities selected by the blog’s operator.
Pingback: BlogSpy.NET
Your examples of existing systems are proofs-of-ownership, for email, cellphone, url,… It sounds like what you’re trying to do is create a new kind of proof, that would reveal less about the user. The token you describe is like a user ID, that is only valid at a single site. Each site would see a different user ID, but the third party knows how to link back these user IDs back to a single user.
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.
Julien –
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!
The problem you will have with such a scheme is that it is visible to the user, and you also have alot of trust issues on who this central authentication person really is, and what they will do with the information. Do I really want a 3rd party to know which bank I use, and which estores I look at? you will have a lot of opposition, as well as 3rd party tracking issues (where people block cookies to 3rd party sites).
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.
Everything that Ian points out is true. This design space is a mine field. You pick your way thru it, and when done it’s childs play to point out that each foot fall is next to a mine. So let me take the issues Ian raises one at a time, not to dismiss them, but to put them into my perspective.
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.