{"id":724,"date":"2007-03-25T12:28:22","date_gmt":"2007-03-25T20:28:22","guid":{"rendered":"\/?p=724"},"modified":"2007-03-25T12:50:00","modified_gmt":"2007-03-25T20:50:00","slug":"delegation-tokens-and-impersonation","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=724","title":{"rendered":"Delegation tokens and impersonation"},"content":{"rendered":"<p>I&#39;ve been asked to&nbsp;clarify a couple of&nbsp;points by Devlin Daley and Bryant Cutler, who are studying with <a href=\"http:\/\/www.windley.com\/\">Phil Windley<\/a>.<\/p>\n<p><strong>Delegation tokens<\/strong>&nbsp;<\/p>\n<blockquote><p>Delegation tokens, as you&#39;ve described them, (according to one of <a href=\"http:\/\/virtualsoul.org\/blog\/2007\/03\/09\/a-field-trip-to-the-planetarium-delegation-authorization-documents-and-auditing\/\">Dale Old&#39;s recent posts<\/a>) are not yet implemented in CardSpace.&nbsp; Is that accurate? Is it soon to be added to specification or is it still a work in progress?<\/p><\/blockquote>\n<p>I like Dale&#39;s piece, but&nbsp;think the &#8220;not&nbsp;yet implemented&#8221;&nbsp;statement might lead to confusion.&nbsp;<\/p>\n<p>One of the key characteristics of CardSpace is that it has no idea what kind(s) of token it is carrying.&nbsp; It&#39;s hard to get this across &#8211;&nbsp;the&nbsp;practical meaning&nbsp;isn&#39;t obvious.&nbsp; But your question about &#8220;delegation tokens&#8221; provides&nbsp; a&nbsp;good concrete example:&nbsp; delegation coupons&nbsp;can be&nbsp;conveyed through CardSpace without any changes or extensions to it.&nbsp; This doesn&#39;t mean anyone is doing so yet.&nbsp; That&nbsp;is likely what Dale is talking about.&nbsp;<\/p>\n<p>I&#39;ve actually been thinking of putting together some demo code to show how this would work.&nbsp; If you look at&nbsp;my <a href=\"\/?p=684\">&#8220;HelloWorld Card&#8221; tutorial<\/a>,&nbsp; you&nbsp;will see that rather than requesting and sending a &#8220;HelloWorld Card&#8221;, the relying party could easily be requesting a delegation coupon.&nbsp; So CardSpace is actually ready for &#8220;delegation coupons&#8221;.<\/p>\n<p>One can then ask what a delegation coupon would look like in concrete terms.&nbsp; What&#39;s the best format for the (possibly multiple) constituent tokens?&nbsp; The blogosphere discussion about delegation shows lots of people are thinking about this, but so far we haven&#39;t built the &#8220;early implementations&#8221; that let us explore the issues and problems concretely enough to emerge with a new standard.&nbsp;&nbsp;I would be interested in learning&nbsp;about research systems built in the academic community to explore this territory &#8211; perhaps you can share your research with us.<\/p>\n<p><strong>Impersonation<\/strong><\/p>\n<p>Devin and Bryant continue:<\/p>\n<blockquote><p>We&#39;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 &#8220;bad&#8221; if I give my express permission for someone to do so? (assuming there is a mechanism for revoking this permission).<\/p>\n<p>In your Powell&#39;s and Amazon example, what if I don&#39;t want Powell&#39;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&#39;t want to disclose that. Is granting the choice to me more user-centric?<\/p><\/blockquote>\n<p>You are quite right that, as per the <a href=\"\/?p=354\">first law of identity<\/a>,&nbsp;the choice of what to disclose must always be in the hands of the user.&nbsp;&nbsp;Further, if&nbsp;a user wants to delegate to a machine the ability to &#8220;be her&#8221;, that should be possible too.&nbsp; Let&#39;s call it <strong>extreme delegation<\/strong>.&nbsp; Our job is not to tell anyone that they should live in some particular way.&nbsp; We might, however, have the responsibility of pointing out the technical dangers of this extreme, perhaps even recommending some interesting science fiction readings&#8230;<\/p>\n<p>But I&#39;ll point out that it isn&#39;t necessary to do&nbsp;impersonation to achieve the goal you want to achieve in your example &#8211; preventing Powell&#39;s from knowing that you are supplying information to Amazon.&nbsp; In fact there are two ways to use delegation to do this.&nbsp;<\/p>\n<p>The first is&nbsp;simply to create a coupon saying, &#8220;the holder of this key has the right to see my Powell&#39;s behavior&#8221;.&nbsp; Then you give Amazon the coupon and the key.&nbsp; In return, Amazon might give you assurances about how it will protect the coupon.&nbsp; Meanwhile, it can retrieve the information it wants without revealing its identity.<\/p>\n<p>Or you may wish to have an agent of your own to which you&nbsp;delegate the ability to&nbsp;assemble your behaviors, and the right to pass them on according&nbsp;to your dictates.&nbsp; I personally think this is the most likely option since it provides optimal user control.&nbsp; But&nbsp;even in this case, designing secure systems means limiting the capabilities delegated to that particular piece of software, rather than &#8220;making it into you&#8221; by having it operate in your identity.&nbsp; There is zero need for impersonation.<\/p>\n<p>Your&nbsp;use case of information hiding can be handled without&nbsp;departing from&nbsp;my <a href=\"\/?p=701\">delegation maxim<\/a>:<\/p>\n<blockquote><p><em>No one&nbsp;and no service&nbsp;should ever&nbsp;act in&nbsp;a peron\u00e2\u20ac\u2122s identity&nbsp;or employ their&nbsp;credentials when they\u00e2\u20ac\u2122re not present.<\/em>&nbsp; Ever.&nbsp;&nbsp;<\/p><\/blockquote>\n<p>Putting several threads together, the user should act through a transducer to delegate to well-identified processes.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The user should act through a transducer to delegate to well-identified processes.<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[32,6,17,8,11,5],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/724"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=724"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/724\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=724"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=724"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=724"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}