{"id":590,"date":"2006-09-24T11:35:21","date_gmt":"2006-09-24T19:35:21","guid":{"rendered":"\/?p=590"},"modified":"2006-09-24T11:36:16","modified_gmt":"2006-09-24T19:36:16","slug":"jon-udell-and-infocards","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=590","title":{"rendered":"Jon Udell and InfoCards…"},"content":{"rendered":"

Good news and a good question from Jon Udell<\/a>.<\/p>\n

Last night I logged into your identity blog using Chuck Mortimore's Firefox extension — very cool!<\/p><\/blockquote>\n

It's great to see Jon excited about Information Cards.<\/p>\n

Now on to that really good question…<\/p>\n

It reminded me to ask you something I've been wondering about. How might following scenario map onto this technology:<\/p>\n

    \n
  1. I join a site (A) that wants to communicate a doc containing my SSN to another site (B)<\/li>\n
  2. Instead of allowing A to hold my SSN, I require A to flow SSN-bearing documents through me enroute to B.<\/li>\n
  3. When the doc arrives, I tack on the SSN. If A must see the doc again before handing off to B, I encrypt the SSN for B's eyes only.<\/li>\n
  4. Along with the SSN I attach a use-once-only-and-then-discard request directed at B.<\/li>\n<\/ol>\n

    (In the example I've been exploring on my blog, and in a podcast<\/a> with Phil Windley<\/a>, A is Prosper.com<\/a> and B is Experian<\/a> or Equifax<\/a>.)<\/p>\n

    It would be interesting to know whether (and if so, how) the Cardspace tech could apply here. Some questions I've thought of:<\/p>\n

    At step 2, do we construe me as the identity provider asserting the claim that is my SSN?<\/p>\n

    Since I am not always online — and assuming the protocol tolerates asynch delay — would we model this as my use of a self-asserted SSN-bearing InfoCard in a B context that was set up by A?<\/p><\/blockquote>\n

    I was a bit confused without refering back to Jon's blog, so here's the piece<\/a> with which he began the discussion:<\/p>\n

    Back in 2003 I was trying to drum up interest in Peter Wayner\u00e2\u20ac\u2122s book, Translucent Databases, which shows how to build and operate databases whose contents are opaque to their operators. Three years later, there\u00e2\u20ac\u2122s still no serious discussion of why translucency should be a key architectural principle, or how it might be applied.<\/p>\n

    A couple of recent examples show why it\u00e2\u20ac\u2122s an issue that belongs on IT\u00e2\u20ac\u2122s agenda. The first involves Prosper<\/a>, a service whose tagline is \u00e2\u20ac\u0153people-to-people lending.\u00e2\u20ac\u009d Using a social network to broker connections between groups of borrowers and groups of lenders, Prosper aims to do for loans what eBay has done for auctionable goods. I wanted to invest a small amount as a lender in order to find out more about how the system works, so I began the sign-up process. To enable a credit check, Prosper asked for my Social Security number. That seems like an obvious requirement but, when you stop and think, why should it be? Prosper doesn\u00e2\u20ac\u2122t actually need to receive and store that number. It only needs to relay it to Equifax, Experian, and TransUnion.<\/p>\n

    If Prosper ran its database translucently, I would be able to encrypt the number so that nobody inside Prosper, legitimate or otherwise, could read it. Equifax and others would ask me to unlock it. Ideally they\u00e2\u20ac\u2122d promise to use it once and then discard it.<\/p>\n

    At this point, of course, it becomes clear that Prosper shouldn\u00e2\u20ac\u2122t need to store my encrypted number in its database. It should only need to sign a request to the bureaus for a credit check. The request should then bounce to me, acquire my encrypted Social Security number along with permission for one-time use, and hop along to the bureaus. This protocol won\u00e2\u20ac\u2122t work synchronously, but it doesn\u00e2\u20ac\u2122t have to. If asynchronous message flow gives me the control I want, that\u00e2\u20ac\u2122ll be just fine.<\/p>\n

    Translucency shouldn\u00e2\u20ac\u2122t apply to only databases; it should govern service networks too. Unfortunately, with the lone exception of SSL, every effort to make cryptographic protocols useful to ordinary folks has gone down in flames. How will that ever change?<\/p>\n

    Quixotic jousts with the likes of Prosper over individual Social Security numbers won\u00e2\u20ac\u2122t move the needle. But AOL\u00e2\u20ac\u2122s recent data spill<\/a>, or another such Exxon Valdez-like disaster, just might. \u00e2\u20ac\u0153My goodness,\u00e2\u20ac\u009d said Thelma Arnold, AOL\u00e2\u20ac\u2122s user #4417749, when her search history was linked to her identity and revealed to her. \u00e2\u20ac\u0153It\u00e2\u20ac\u2122s my whole personal life.\u00e2\u20ac\u009d<\/p>\n

    It\u00e2\u20ac\u2122s time for a public conversation about the uses and limits of translucency. Is it really necessary to retain my Social Security number, or my search history, in order to provide a service? If not, what does it cost the provider of a service — and cost the user, for that matter — to achieve the benefit of translucency? Is this kind of opt-out a right that users of services should expect to enjoy for free, or is it a new kind of value-added service that provider can sell?<\/p>\n

    Realistically, given the very real technical challenges, I think it would have to be a service. Until recently, that hadn\u00e2\u20ac\u2122t been a service that many folks would have considered paying for. But Thelma Arnold and 658,000 other AOL customers probably see things differently now. If you\u00e2\u20ac\u2122d rather not be liable for storing more of your customers\u00e2\u20ac\u2122 data than is strictly necessary, that\u00e2\u20ac\u2122s a step in the right direction.<\/p><\/blockquote>\n

    This is one of several related items, all of which are interesting.  I'll let you rest your eyes, and respond in my next post.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Quixotic jousts over individual Social Security numbers won\u00e2\u20ac\u2122t move the needle. But AOL\u00e2\u20ac\u2122s recent data spill, or another such Exxon Valdez-like disaster, just might. <\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[16,6,15,5],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/590"}],"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=590"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/590\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=590"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=590"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=590"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}