Ben Laurie blathering

You Need Delegation, Too

Kim wants to save the world from itself. In short, he is talking about yet another incident where some service asks for username and password to some other service, in order to glean information from your account to do something cool. Usually this turns out to be “harvest my contacts so I don’t have to find all my friends yet again on the social network of the month”, but in this case it was to calculate your “Twitterank”. Whatever that is. Kim tells us

The only safe solution for the broad spectrum of computer users is one in which they cannot give away their secrets. In other words: Information Cards (the advantage being they don’t necessarily require hardware) or Smart Cards. Can there be a better teacher than reality?

Well, no. There’s a safer way that’s just as useful: turn off your computer. Since what Kim proposes means that I simply can’t get my Twitterank at all (oh, the humanity!), why even bother with Infocards or any other kind of authentication I can’t give away? I may as well just watch TV instead.

Now, the emerging answer to this problem is OAuth, which protects your passwords, if you authenticate that way. Of course, OAuth is perfectly compatible with the notion of signing in at your service provider with an Infocard, just as it is with signing in with a password. But where is the advantage of Infocards? Once you have deployed OAuth, you have removed the need for users to reveal their passwords, so now the value add for Infocards seems quite small.

But if Infocards (or any other kind of signature-based credential) supported delegation, this would be much cooler. Then the user could sign a statement saying, in effect, “give the holder of key X access to my contacts” (or whatever it is they want to give access to) using the private key of the credential they use for logging in. Then they give Twitterank a copy of their certificate and a copy of the new signed delegation certificate. Twitterank presents the chained certificates and proves they have private key X. Twitter checks the signature on the chained delegation certificate and that the user certificate is the one corresponding to the account Twitterank wants access to, and then gives access to just the data specified in the delegation certificate.

The beauty of this is it can be sub-delegated, a facility that is entirely missing from OAuth, and one that I confidently expect to be the next problem in this space (but apparently predicting such things is of little value – no-one listens until they hit the brick wall lack of the facility puts in their way).


  1. There was a lot of interest in adding this use case (or at least not preventing it) at the IETF OAuth BoF. There were questions on the central role of the Service Provider in the OAuth architecture and whether that was a requirement. My view is that it doesn’t and there is no reason why OAuth should limit Access Tokens generated directly by the User. This will probably get discussed at the IETF working group.

    Comment by Eran Hammer-Lahav — 20 Nov 2008 @ 19:07

  2. Couldn’t agree more with the “brick wall” comment. Made me laugh:)

    Related to your chained delegation, could we apply this to a transaction such that the user’s desired transaction is approved no matter which services it needs to pass through, but the “authorization” is only good for the transaction?

    Comment by George Fletcher — 20 Nov 2008 @ 20:36

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress