{"id":433,"date":"2006-04-17T12:40:45","date_gmt":"2006-04-17T20:40:45","guid":{"rendered":"\/?p=433"},"modified":"2006-04-17T12:43:58","modified_gmt":"2006-04-17T20:43:58","slug":"adam-on-demystifying-infocards","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=433","title":{"rendered":"ADAM ON DEMYSTIFYING INFOCARDS"},"content":{"rendered":"<p>Adam at <a href=\"http:\/\/www.emergentchaos.com\">Emergent Chaos<\/a>&nbsp;has <a href=\"http:\/\/www.emergentchaos.com\/archives\/2006\/04\/infocard_demystified.html\">taken a stab<\/a> at&nbsp;demystifying InfoCards:<\/p>\n<blockquote><p>For every product, there are thousands of sentences which result in the reply &#8220;well, why didn&#39;t you just say that?&#8221; The answer, of course, is that there are thousands, and often its not clear which is the right one. For me, the useful sentence is that &#8216;Infocard is software that packages up identity assertions, gets them signed by a identity authority and sends them off to a relying party in an XML format. The identity authority can be itself, and the XML is SAML, or an extension thereof, and the XML is signed and encrypted.&#8217;<\/p><\/blockquote>\n<p>Hmmm.&nbsp; Thanks Adam.&nbsp; No cigar, but we&#39;re getting closer.<\/p>\n<p>Actually, the relying party states what assertions it wants, the Identity Selector&nbsp;allows the user to control&nbsp;what identity provider to use, and the identity provider packages up the identity assertions, signs them and sends them to the relying party in a token&nbsp;format.&nbsp; The identity authority can be&nbsp;something local to the identity selector, or something reachable over the internet, and the token format can be XML, including&nbsp;SAML, or anything else.&nbsp;&nbsp;The whole visual metaphor and user experience&nbsp;is called InfoCard, the protocols are WS-Trust, and the mesh of interoperating parties and technologies are the Identity Metasystem.<\/p>\n<p>It feels like together we have put together a pretty good definition.&nbsp; Comments?<\/p>\n<blockquote><p>Why didn&#39;t you just say that? (Actually, Kim Cameron says just about that in the video linked to in &#8220;<a href=\"\/?p=428\"><font color=\"#3b4c37\">The Infocards For PHP Tutorial<\/font><\/a>.&#8221;)<\/p><\/blockquote>\n<p>True.&nbsp; Why didn&#39;t I just say that?<\/p>\n<blockquote><p>More seriously, I&#39;m unsure if Infocard is the software, the protocol, or some combination thereof. But I do have a much better understanding of how it works, so I&#39;m glad to have watched the short movie demo.<\/p><\/blockquote>\n<p>Yes, I&#39;ve been sloppy about all of this, and the fact that InfoCard is just a code name doesn&#39;t help either.&nbsp; Anyway, InfoCard is&nbsp;really the visualization and experience that represents an identity within&nbsp;an identity selector.&nbsp;<\/p>\n<blockquote><p>A couple of thoughts:<\/p>\n<ul>\n<li>First, Stephan Brands of <a href=\"http:\/\/credentica.com\/\"><font color=\"#192e1a\">Credentica<\/font><\/a> has comprehensively analyzed the privacy issues in this sort of scheme in his book, &#8220;<a href=\"http:\/\/credentica.com\/the_mit_pressbook.php\" class=\"broken_link\"><font color=\"#192e1a\">Rethinking Public Key Infrastructures and Digital Certificates; Building in Privacy<\/font><\/a>.&#8221; The essential point to be aware of is that the certifying authority can track every site you visit. Infocard includes a self-signing authority, so you&#39;re aware of every site you visit. If web sites start demanding certificates from other organizations, they have a deep view into your web activities.<\/li>\n<\/ul>\n<\/blockquote>\n<p>See my&nbsp;comments below&#8230;<\/p>\n<blockquote>\n<ul>\n<li>The <a href=\"https:\/\/www.identityblog.com\/infocard-demo.php\" class=\"broken_link\"><font color=\"#192e1a\">demo code<\/font><\/a> relies on Javascript. Is there anything other than the &#8220;onClick&#8221; that requires it? Javascript dramatically expands the browser&#39;s attack surface, helps phishers confuse users, etc. It would be good for Infocard to work without relying on it.<\/li>\n<\/ul>\n<\/blockquote>\n<p>I need to think more about this.<\/p>\n<blockquote>\n<ul>\n<li>Finally, there&#39;s a card which is greyed out, which Kim helpfully explains is greyed out because it doesn&#39;t include an email address. I&#39;m expecting there&#39;s an easy way for the user to discover this?<\/li>\n<\/ul>\n<p>Anyway, I&#39;m glad that Kim produced the video, and if you&#39;ve been like me, watching and not having time to dig in, <a href=\"\/?p=428\"><font color=\"#3b4c37\">go watch it<\/font><\/a>.<\/p><\/blockquote>\n<p>I&#39;m happy the video is helping clarify things.&nbsp;&nbsp;InfoCards are really easy to use, but hard&nbsp;to explain to a technical audience.<\/p>\n<p><strong>No tracking<\/strong>&nbsp;<\/p>\n<p>I&nbsp;have to&nbsp;correct Adam&#39;s assertion that&nbsp;&#8220;the certifying authority can track every site you visit&#8221;.<\/p>\n<p>The InfoCard system supports what we call &#8220;non-auditing&#8221; identity providers.&nbsp;As I say in&nbsp;the tutorial accompanying the video:<\/p>\n<blockquote><p>The InfoCard system supports two classes of Identity Provider.<\/p>\n<li>&#8220;auditing&#8221; identity providers know what Relying Party the subject is visiting. They therefore encrypt directly to the relying party.<\/li>\n<li>&#8220;non-auditing&#8221; identity providers, are not, for privacy reasons, told the identity of the relying party. Therefore, they can&#39;t encrypt for it. Instead, they send the token to the InfoCard client, which in turn encrypts it for the Relying Party.<\/li>\n<\/blockquote>\n<p>Non-auding identity providers don&#39;t have&nbsp;visibility into the sites you visit.<\/p>\n<p>Stephan&#39;s work &#8211; which I would like to see incorporated into the InfoCard framework &#8211; adds a proof-key to the bearer semantics currently used for non-auditing providers. This strengthens the proof of ownership of the token and is a good thing, but it doesn&#39;t affect the privacy of the system.<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>So far, no cigar, but maybe we&#39;re lurching closer.<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/433"}],"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=433"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/433\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=433"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=433"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=433"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}