Most web login schemes work the same way. When the site becomes curious and wants to know more about the user it delegates that task to identity provider. The identity provider then authenticates the user and sends him back to the original site. Information about the user can then be sent via back channel of one kind or another. Lots of schemes exist for implementing these back channels: shared cookies, extra CGI parameters, full fledged TCP back channels.

Building a good identity service is delicate work. People screw it up because it’s hard. Criminals spend a lot of time working out schemes to trick the identity server into misbehaving.

Here’s a way to get it wrong: let untrusted parties bounce off your login server. In this example eBay’s the one that messed up. The problem? Phisher’s entice users to go to their eBay account an log in. Once log on the user is bounced over to the phisher’s web site. The user at that point thinks he’s talking to eBay; but he’s not. He’s talking to a bad guy.

The user thinks, when he logs into eBay, that he’s entering the world of eBay. This is similar to what in Liberty is call the circle of trust. As a rule of thumb identity servers shouldn’t provide services to unknown sites. The users presume that sites reached directly via the login server have some degree, no matter how slight, of trust among them.

It’s possible that an extremely lite weight identity system, like OpenID, could break this rule. The cost of conforming to the rule is two fold. It makes it harder to run an ID service, since you have to provision and maintain an account relationship with every site you service. More critical from a business model point of view – you raise the barrier to entry for additional sites adopting your service.

Personally I think ID services should always have an account relationship with the sites they serve. They can then hang a lot of useful junk off that account data; for example a list of URL patterns they are willing to bounce back to.

Every time you see data stuffed into a URL you obviously need to worry about what that might be revealing about the user which ought to be kept private. What’s less obvious is how every time you see an URL getting bucket brigaded along you need to puzzle out how the user’s trust model is changing as he travels. That URL can tap that trust. The first worry is about stealing bits of the user’s privacy. The second is about stealing bits of trust off the intermediaries.