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.