I've been asked to clarify a couple of points by Devlin Daley and Bryant Cutler, who are studying with Phil Windley.
Delegation tokens, as you've described them, (according to one of Dale Old's recent posts) are not yet implemented in CardSpace. Is that accurate? Is it soon to be added to specification or is it still a work in progress?
I like Dale's piece, but think the “not yet implemented” statement might lead to confusion.
One of the key characteristics of CardSpace is that it has no idea what kind(s) of token it is carrying. It's hard to get this across – the practical meaning isn't obvious. But your question about “delegation tokens” provides a good concrete example: delegation coupons can be conveyed through CardSpace without any changes or extensions to it. This doesn't mean anyone is doing so yet. That is likely what Dale is talking about.
I've actually been thinking of putting together some demo code to show how this would work. If you look at my “HelloWorld Card” tutorial, you will see that rather than requesting and sending a “HelloWorld Card”, the relying party could easily be requesting a delegation coupon. So CardSpace is actually ready for “delegation coupons”.
One can then ask what a delegation coupon would look like in concrete terms. What's the best format for the (possibly multiple) constituent tokens? The blogosphere discussion about delegation shows lots of people are thinking about this, but so far we haven't built the “early implementations” that let us explore the issues and problems concretely enough to emerge with a new standard. I would be interested in learning about research systems built in the academic community to explore this territory – perhaps you can share your research with us.
Devin and Bryant continue:
We've been bantering about the idea of delegation vs. impersonation. Clearly impersonating someone without them knowing is wrong and a serious problem. But, is impersonation “bad” if I give my express permission for someone to do so? (assuming there is a mechanism for revoking this permission).
In your Powell's and Amazon example, what if I don't want Powell's to know that I am supplying this information to Amazon? Obviously there are cases where we want to let others know that services are acting with our permission. Perhaps there are cases where we don't want to disclose that. Is granting the choice to me more user-centric?
You are quite right that, as per the first law of identity, the choice of what to disclose must always be in the hands of the user. Further, if a user wants to delegate to a machine the ability to “be her”, that should be possible too. Let's call it extreme delegation. Our job is not to tell anyone that they should live in some particular way. We might, however, have the responsibility of pointing out the technical dangers of this extreme, perhaps even recommending some interesting science fiction readings…
But I'll point out that it isn't necessary to do impersonation to achieve the goal you want to achieve in your example – preventing Powell's from knowing that you are supplying information to Amazon. In fact there are two ways to use delegation to do this.
The first is simply to create a coupon saying, “the holder of this key has the right to see my Powell's behavior”. Then you give Amazon the coupon and the key. In return, Amazon might give you assurances about how it will protect the coupon. Meanwhile, it can retrieve the information it wants without revealing its identity.
Or you may wish to have an agent of your own to which you delegate the ability to assemble your behaviors, and the right to pass them on according to your dictates. I personally think this is the most likely option since it provides optimal user control. But even in this case, designing secure systems means limiting the capabilities delegated to that particular piece of software, rather than “making it into you” by having it operate in your identity. There is zero need for impersonation.
Your use case of information hiding can be handled without departing from my delegation maxim:
No one and no service should ever act in a peronâ€™s identity or employ their credentials when theyâ€™re not present. Ever.
Putting several threads together, the user should act through a transducer to delegate to well-identified processes.
3 thoughts on “Delegation tokens and impersonation”
Here's some pointers to research that might me useful. Don't assume this is complete. Type “Trust Management” at Google. Look for author's names like Blaze, Feigenbaum, Li (again incomplete). Look for systems like Keynote, Referee, etc. Follow the references. Walk down the hall and ask Carl Ellison to bloviate about SPKI; that's an old one, but still has relevance, methinks.
And if you want to see some serious mathematics about the subject (this isn't for the faint of heart), try“Understanding Trust Management Systems, by Stephen Weeks.
Kim Cameron replies Thanks Eric. That is really a magical search term, and these are all very good recommendations.
I wasn't really asking as much for a general introduction to academic security, as for guidance about novel exploratory systems built in the last few years. None the less, my takeaway is that we need to put together a pithy reading list on the former subject.
Regarding your suggestion that I “walk down the hall”, I can assure you I do so all the time. I built interesting systems with raw keys back in the ’80s and was a big fan of SDSI and SPKI. Naturally I have discussed these issues at length with Carl Ellison – who is really interested in identity.
Since coming to Microsoft I've also been lucky enough to speak with Butler Lampson from time to time. As you will know, the very interesting Weeks paper you cite is heavily indebted to his “speaks-for” calculus. Incredibly, Butler also did much of the design of Cal TSS, the groundbreaking “capabilities-based” system, back in the late 60’s. I happened to be meeting with Butler just after reading one of Ben Laurie's posts, and asked him what he thought of Ben's notion that delegation could perhaps be collapsed into “capabilities”. I will write about his answer one day.
Talking about influences, I need to mention Paul Leach, wiseman and major contributor to distributed system security. I'm somewhat familiar with Feigenbaum and Li, and will look into their work further. More recently, I've been influenced by the ideas of Stefan Brands and Jan Camenisch. I know there are really important influences I've forgotten here – hope no one will notice.
Comments are closed.