Links

Ben Laurie blathering


Kim Cameron on Me on Selective Disclosure

Kim has a couple of posts responding to my paper on selective disclosure and my claim that CardSpace does not obey his fourth law.

First off, Kim thinks I shouldn’t say unlinkability and verifiability are things that an identity system should be required to support, on the basis that sometimes you want to be linked, and sometimes you don’t need verification. Well, of course … perhaps he didn’t notice that I said “here are three properties assertions must be able to have” – I didn’t say that every assertion should have these properties.

He also does not like this statement

Note a subtle but important difference between Kim’s laws and mine – he talks about identifiers whereas I talk about assertions. In an ideal world, assertions would not be identifiers; but it turns out that in practice they often are.

He claims that, in fact, his laws are about assertions. Allow me to quote his fourth law in full

A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

You will note that this law talks about identifiers. Not identities. Not assertions. The point I am trying to make is that assertions are identifiers when they are signed using conventional signatures. This is because each time a signed assertion is presented it is identical to the last time it was presented, and different from all other signed assertions (since it must be linked to the identity of the subject of the assertion, or it is useless). The very core of my argument is that unless assertions are unlinkable, then they are identifiers – and, what’s more, they are omnidirectional identifiers. Therefore the “identity metasystem” as currently implemented cannot obey Kim’s fourth law.

Finally, he attempts to show that I am wrong about this claim, with the following argument

How does CardSpace hide the identity of the relying party? It associates some random information – unknown to the identity provider – with each Information Card. Then it hashes this random information (let’s call it a “salt”) with the identity of the site being visited. That is conveyed to the identity provider instead of the identity of the site. We call it the “Client Pseudonym”. Unlike a Liberty Alliance client pseudomym, the identity provider doesn’t know what relying party a client pseudonym is associated with.

The identity provider can use this value to determine that the user is returning to some site she has visited before, but has no idea which site that would be. Two users going to the same site would have cards containing different random information. Meanwhile, the Relying Party does not see the client pseudonym and has no way of calculating what client pseudonym is associated with a given user.

Of course, if the identity provider and the relying party never talk to each other, then this works just fine. But clearly it is easy for the two of them to put their heads together and find out who the user is. I require unlinkability even if everyone gangs up to track the user. So, this argument totally fails to satisfy my requirement.

I’m looking forward to the next post in Kim’s series…

The question now becomes that of how identity providers behave. Given that suddenly they have no visibility onto the relying party, is linkability still possible? I’ll discuss this next.

5 Comments

  1. The very core of my argument is that unless assertions are unlinkable, then they are identifiers – and, what’s more, they are omnidirectional identifiers.

    What about assertions that are encrypted for “your eyes only”? To anyone else, they’re just random, meaningless, useless gibberish. I sure would call them unidirectional. to use Kim’s terminology. Isn’t this what CardSpace does when appropriate?

    Comment by Eric Norman — 3 Jun 2007 @ 23:30

  2. An assertion, whether encrypted or not, is a fixed object. Everyone who has seen it – which is at least the issuer and the relying party – can link it, if they collude. Of course, the transitive closure of this gives you linkage back to the user.

    Comment by Ben — 4 Jun 2007 @ 6:06

  3. […] Inspired by some of Ben Laurie’s recent postings, I want to continue exploring the issues of privacy and linkability (see related pieces here and here).  […]

    Pingback by Kim Cameron’s Identity Weblog » Linkage and identification — 4 Jun 2007 @ 7:08

  4. […] Following up on Ben Laurie’s excellent introduction to selective disclosure, Kim Cameron and Ben have been blogging on the properties of unlinkability and selective disclosure. See here, here, here, and here, as well as this older post of Ben’s. […]

    Pingback by The Identity Corner » On Identity Claims, Unlinkability, and Selective Disclosure (part 1) — 4 Jun 2007 @ 18:00

  5. I see. The “if they collude” qualificaiton is essential. After rereading the original post, I see that’s exactly what you said (… even if everyone gangs up to track the user).

    So, I think before you guys continue arguing about whose laws are better, it would be nice to have some agreement about the collusion stuff. Is it always assumed? Is it easy to effect? Would parties have a motivation to collude?

    I take that back. It’s an interesting discussion regardless of the collusion factor. Debate away.

    Comment by Eric Norman — 5 Jun 2007 @ 0:14

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress