{"id":651,"date":"2007-01-14T22:33:25","date_gmt":"2007-01-15T06:33:25","guid":{"rendered":"\/?p=651"},"modified":"2007-01-14T22:33:25","modified_gmt":"2007-01-15T06:33:25","slug":"resending-of-personal-data-with-infocards","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=651","title":{"rendered":"Resending of personal data with InfoCards"},"content":{"rendered":"

Eric Schultz writes with this question: <\/p>\n

I've been investigating CardSpace and the practicality of it's use for login on a new social networking site.<\/p>\n

I have a question regarding the method through which data is transferred. I see that you can require certain claims from an InfoCard such as email, first and last name, zip code etc. When I look at the login code I see that the same claims are required again.<\/p>\n

Does this mean that each time an InfoCard is sent all the personal data is resent? Isn't this dangerous for security\/privacy? The potential for a server failure (malicious or not) caused by a buffer overflow, a coding mistake that outputs the details of session variables etc. seems rather risky in this scenario.<\/p>\n

Perhaps I am being alarmist?<\/p><\/blockquote>\n

This is an area in which being “an alarmist” – perhaps I will rephrase it as being thoroughly pessimistic about what can go wrong – is the best starting point.  You questions are ones everyone should think about.<\/p>\n

InfoCard and Minimal Disclosure<\/strong><\/p>\n

The simple answer is that there is nothing built into InfoCard concepts that requires a “relying party” to ask for attributes every time a user comes to its site.  Let's first look at the mechanics. <\/p>\n

The relying party controls what attributes it asks for by putting an OBJECT tag in the HTML page where the user opts to use an infocard.<\/p>\n

<\/p>\n

The example shown here will bring up the infocard dialog and illuminate any cards that offer all four claims so the user can select one. <\/p>\n

If, next time, the relying party doesn't want to receive these claims, it just doesn't ask for them.  If it has stored them, it should be able to retrieve them when necessary by using  “privatepersonalidentifier” as a handle.  This identifier is just a random pairwise number meaningless to any other site, and so there is no identity risk in using it.<\/p>\n

No theoretical bias<\/strong> <\/p>\n

In other words, the InfoCard system has no theoretical bias about what information should be asked for when.  Through the Laws of Identity we have tried to help people understand that they should only ask for what they need to complete a transaction and should only keep it for the length of time they absolutely must. <\/p>\n

In particular, there should be no hoarding of rainy-day information<\/em><\/strong> – information that “might come in handy” some day – but which is more likely to turn into a liability than into a benefit.<\/p>\n

Do your risk analysis<\/strong> <\/p>\n

You'll need to do the conventional risk analysis and think about whether it is more dangerous to store the information or just ask for it on an “as-needed” basis and then forget it.  My personal sense is that it is more dangerous to store it than to use an on-demand approach. <\/p>\n

A central machine with the stored information that animates a successful internet business is a honeypot.  It could well be subject to insider attacks, and certainly, since it lives on the internet, will be subject to many attacks on the information it stores.  Why not avoid these problems completely?<\/p>\n

Certainly, the on-demand approach has benefits in convincing customers and legal practitioners that, having held no identity information, you cannot be seen as being responsible for an identity meltdown.  To me this is very attractive, and something that has not been possible until now.<\/p>\n

Conclusion<\/strong><\/p>\n

The examples Eric gives of things that can go wrong seem to me to apply even more strongly if you have stored information locally than if you ask for it on demand.<\/p>\n

But as I said earlier, this just expresses my thinking – there is lots more to be written by Eric and hundreds of others as they develop applications. <\/p>\n

Meanwhile, InfoCard has no built-in assumptions around this and can be used in whatever way is appropriate to a given situation.<\/p>\n

 <\/p>\n

<\/font><\/p>\n","protected":false},"excerpt":{"rendered":"

What are the relative benefits and problems of storing people's personal information versus asking for it on demand?<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[16,2,14,11,4],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/651"}],"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=651"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/651\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=651"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=651"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=651"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}