{"id":892,"date":"2007-11-18T18:44:46","date_gmt":"2007-11-19T02:44:46","guid":{"rendered":"\/?p=892"},"modified":"2008-03-05T21:19:11","modified_gmt":"2008-03-06T05:19:11","slug":"display-tokens-in-information-cards","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=892","title":{"rendered":"Display Tokens in Information Cards"},"content":{"rendered":"

I recommend an interesting exchange between Citi's Francis Shanahan<\/a>, Microsoft's Vittorio Bertocci<\/a>, and University of Wisconsin's Eric Norman.<\/a>\u00a0 Here's the background.\u00a0 Francis has spent a lot of time recently looking in depth at the way CardSpace uses WS-Trust, and even built a test harness <\/a>that I will describe in another piece.\u00a0 While doing this he found something he\u00a0thought was surprising:\u00a0 CardSpace doesn't show the user the actual binary token\u00a0sent to a relying party\u00a0– it shows\u00a0a description crafted by the identity provider to best communicate with the user.<\/p>\n

(The behavior of the system on this\u00a0– and other –\u00a0points is documented in a paper Mike Jones<\/a> and I put together quite a while ago called “Design Rationale Behind the Identity Metasystem Architecture<\/a>“.\u00a0 There is a link to it in the WhitePapers section<\/a> on my blog.)<\/p>\n

Francis has his priorities straight, given the way he sees things:<\/p>\n

I'm not sure how to solve this. I'm not sure if it's a fault inherent in the Identity Meta-system or if it's just a fact of life we have to live with.<\/p>\n

I would never want to put the elegance of a meta-system design and accommodation of potential future token types ahead of supporting Law #1.<\/p><\/blockquote>\n

There is no question that elegance of design cannot be pitted against the Laws of Identity without causing the whole design to fail and\u00a0any purported elegance to evaporate.<\/p>\n

So clearly I\u00a0think that the current design delivers the user control and consent\u00a0mandated by\u00a0the First Law of Identity.\u00a0<\/p>\n

Let's start by\u00a0seeing the\u00a0constraints\u00a0from a\u00a0practical point of view.\u00a0 In an auditing identity provider, one of the main characteristics of the system is that the provider knows the identity of the relying party.\u00a0 Think of the consequences.\u00a0 The identity provider\u00a0is capable of\u00a0opening a back channel to\u00a0any relying party and telling it whatever it wants to<\/em>.\u00a0 In fact, from a purely technical point of view, the identity provider can just broadcast all the information it knows about\u00a0you, me and all our activities\u00a0to the entire world!\u00a0<\/p>\n

We put trust in the identity provider when we provide it with information that we don't want universally known.\u00a0 And more trust is involved when we accept “auditing mode”, in which the identity provider is able to help protect us by seeing the identity of the party we are connecting with (e.g. during a banking transaction).<\/p>\n

Should we\u00a0conclude the existence of\u00a0scenarios\u00a0requiring auditing\u00a0mean the laws aren't “laws”?<\/p>\n

“Going back to my original question which was “Does the DisplayToken violate the First Law of Identity?” I am not convinced it does. What I think I am discovering is that the First Law of Identity is not necessarily enforced.<\/p>\n

“For me, being Irish Catholic (and riddled with guilt as a result) I take a very hard-line approach when you start talking about “Laws”. For example, I expect the Law of Gravity to be obeyed. I don't view it as a “Recommendation for the Correct Implementation of Gravity”…<\/p><\/blockquote>\n

The point here is that when the user employs an auditing identity provider, she should understand that's what she is doing.\u00a0<\/p>\n

While we can't then prevent evil, we can detect and punish it.\u00a0 The claims in the token are cryptographically bound to the claims in the display token.\u00a0 The binding is auditable.\u00a0 So\u00a0policy enforcers\u00a0can now audit that the human readable claims, and associated information policy,\u00a0convey the nature of the underlying information transfer.\u00a0\u00a0<\/p>\n

This auditability means it is possible to determine if identity providers are abiding by the information policies they claim\u00a0they are employing.\u00a0\u00a0This provides a handle for\u00a0enforcing and regulating the behavior of system participants.<\/p>\n

We've spoken so far about “auditing” identity providers.\u00a0 The system also supports “non-auditing” providers, who do not know the identity of the relying party.\u00a0 In this case, a back channel is not possible.\u00a0 The auditing of the accuracy of the display token is still possible however.<\/p>\n

There is also an option for going even further, through the use of “minimal disclosure tokens”.\u00a0\u00a0In such a system, the user can have an identity provider that\u00a0she operates, and which submits her claims to a service for validation.\u00a0 In this architecture, the user can really be guaranteed that there are no back\u00a0channels or identity-provider injected goop.<\/p>\n

Again, we are brought to understand that the identity metasystem spans a whole series of requirements, use cases and behaviors.\u00a0\u00a0The most important thing is that it\u00a0support all<\/em> of them.\u00a0<\/p>\n

I do not want a “non-auditing” bank account.\u00a0\u00a0In\u00a0that context,\u00a0display tokens bound to information tokens and associated with an information policy all seem fine to me.<\/p>\n

On the other hand, when\u00a0browsing the web and doing many other types of transactions I\u00a0want\u00a0to prevent\u00a0any identity provider from profiling me or obtaining any more information than necessary.\u00a0 Minimal disclosure tokens\u00a0are the best answer\u00a0under those circumstances.<\/p>\n

The uberpoint:\u00a0 unless we have a system that embraces all these use cases, we break more than the first law.\u00a0 We break the laws of minimal disclosure, necessary parties, identity beacons, polymorphism, human integration and consistent experience.\u00a0\u00a0 We need a balanced, pragmatic approach\u00a0that builts transparency, privacy, user control and understanding into the system\u00a0–\u00a0integrated with a legal framework for the digital age.<\/p>\n","protected":false},"excerpt":{"rendered":"

Again we see that the identity metasystem spans a whole series of requirements, use cases and behaviors<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[49,16,37,6,8,7],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/892"}],"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=892"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/892\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=892"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=892"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=892"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}