{"id":589,"date":"2006-09-20T11:53:15","date_gmt":"2006-09-20T19:53:15","guid":{"rendered":"\/?p=589"},"modified":"2006-09-20T13:46:11","modified_gmt":"2006-09-20T21:46:11","slug":"identityblog-and-your-identity-information","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=589","title":{"rendered":"Identityblog and your identity information"},"content":{"rendered":"<p>Matt, a&nbsp;reader who downloaded Ian Brown&#39;s early version of <a href=\"\/?p=579\">Information Cards for Safari<\/a>, wrote to me with the following&nbsp;question:<\/p>\n<blockquote><p>I just signed up to your identity blog using the Safari CardSpace selector you mentioned on your blog.<\/p>\n<p>I&#39;m interested to know whether the (genuine) identity data in my CardSpace selector (populated out of my Address Book entry I think) is transmitted to you, if it is where it is stored, and what is done with it and to protect it.<\/p><\/blockquote>\n<p>Matt is&nbsp;unclear about what information he has sent to&nbsp;Identityblog because the Safari and Firefox&nbsp;user interfaces don&#39;t yet deal with&nbsp;displaying <strong><em>what subset<\/em> <em>of the information&nbsp;in a card<\/em><\/strong>&nbsp;is being asked for by the site he is visiting.&nbsp;<\/p>\n<p>That&#39;s because&nbsp;the current versions&nbsp;are very much&nbsp;prototypes and&nbsp;works in progress.&nbsp; As Ian <a href=\"http:\/\/www.hccp.org\/safari-plug-in.html\">says on his blog<\/a>:<\/p>\n<blockquote><p>This is currently still at the proof of concept stage, and is lacking most of the features found in the official CardSpace selector from Microsoft.<\/p><\/blockquote>\n<p>This being said, I have verified&nbsp;that the demo Firefox selector only releases <strong>required<\/strong> claims, and I&#39;m pretty sure the Safari selector follows suit.&nbsp;<\/p>\n<p>The current Cardspace interface design was&nbsp;refined&nbsp;through&nbsp;ongoing &#8220;usability work&#8221; in which&nbsp;we&nbsp;encountered this kind of confusion and explored (and measured the efficacy of) different alternatives&nbsp;for avoiding it.<\/p>\n<p>As a result, when you release any new information to a site within Cardspace you see a screen like this one:<\/p>\n<p><img src=\"\/wp-content\/resources\/simple-infocard-demo\/2006\/09\/what-fields.gif\" \/>&nbsp;<\/p>\n<p>It doesn&#39;t matter&nbsp;whether&nbsp;a user&nbsp;has filled out&nbsp;other fields in&nbsp;their chosen Information Card.&nbsp; Only the fields asked for by the site&nbsp;will be&nbsp;presented for approval.&nbsp;&nbsp;Then the user can decide whether to proceed or not.<\/p>\n<p>On subsequent visits to a site, the information release screen is not shown by default.&nbsp; The thinking is that once information has been released once, it forms part of the &#8220;contract&#8221; between the user and the site.&nbsp; If&nbsp;we were to ask the user to &#8220;approve&#8221; the release time after time, the release page would become nothing more than a &#8220;click through page&#8221; &#8211; meaning the user&nbsp;wouldn&#39;t even &#8220;see&#8221; it.<\/p>\n<p>As for what I store, my approach is to ask for as little information as I can.&nbsp;<\/p>\n<p>I request an email address so I can verify that you are not a spammer, and so you can change your infocard by using the email address as an &#8220;alternate authentication channel&#8221; (more on this in a future post).&nbsp; I&#39;m working with some friends on a version where we won&#39;t store the actual email address &#8211;&nbsp;we will&nbsp;use a hash of it instead so we can recognize you but not expose your address to possible breaches.<\/p>\n<p>I also store what you&#39;ve given me as a first and last name because WordPress uses that to show who has written posts and comments.&nbsp; I&nbsp;will eventually&nbsp;change this so I only store&nbsp;your names&nbsp;once you have written a post or comment (i.e. done something &#8216;public&#8217;).<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Cardspace shows the user the information a site has asked for, displaying it for approval before first release.  <\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[16,6,7,9],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/589"}],"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=589"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/589\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=589"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=589"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=589"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}