Links

Stefan Brands writes eloquently about the spectrum of uses available when selective disclosure is employed, which I might paraphrase as ranging from “anonymous” to “completely privacy invading”, contrary to many peoples’ perceptions. Selective disclosure is often seen as a purely privacy-preserving technology; but that misses the point. Selective disclosure allows the full spectrum of options – from nothing at all to everything. Other signature mechanisms and technologies do not. It’s as simple as that.

One thing that intrigues me, though, is his statement at the end: that the issuer has the ability to control what is revealed. I’m dubious about the value of this property. The user should be aware of this control and therefore able to choose whether to show the certificate at all. Similarly, the relying party can refuse to continue the transaction unless his requirements for disclosure are satisfied. What did the identity provider add by having a hand in this decision?

Share This

As far as I know, I’m the only person that does this, so I thought I’d document it.

First of all, I use iTunes on Windows to rip my CDs. I used to use grip on FreeBSD, but iTunes does a more reliable job, particularly with “copy protected” CDs. Once ripped, the MP3s live on the FreeBSD box. LongPlayer, which plays randomly, biased by your rating of each track, then feeds them to XMMS. A slightly strange quirk here is that the audio then goes through my Windows box, which is what I use as my desktop (with VNC to get at my Unix boxes), so I get cheap mixing – that is, I can hear things go “bong” while the music is playing. As I’m listening (which is essentially never with my full attention) I score tracks. My scoring system looks like this:

• 4 or less: I don’t want to hear this track
• 5: Not yet scored (LongPlayer defaults to 5)
• 6: Not objectionable, but don’t mind if I never hear it again
• 7: Nice but not superb
• 8: Superb
• 9: Exceptionally superb

I suppose I should use 10 for something, but I ran out of imagination. Of course, I’m often not paying enough attention to score things, which leads to a problem: new tracks sit on 5, which means they don’t get played very often (even tracks scoring 7 or 8 only get played every 6-9 months!). Until recently I’ve fixed this by occasionally requeuing all the unscored tracks from the LongPlayer GUI, but last weekend I finally got around to writing a couple of scripts, driven by an XML export of LongPlayer’s playlist. One of them trawls through the entire MP3 collection and finds tracks LongPlayer has never played, and queues them – LongPlayer seems to be a bit erratic about finding new tracks. The other trawls through LongPlayer’s playlist and queues tracks that have a score of 5 (i.e. unscored). Repeated applications of these utilities should eventually lead to everything being scored.

The final component of my music puzzle is another utility I wrote that takes LongPlayer’s playlist and produces an M3U (i.e. a standard playlist, which is just a list of files) of all tracks I’ve scored 8 or higher. I then use this playlist to drive my SliMP3 in my kitchen – which, apart from my bed, is where I spend the most time outside my office. I also use the M3U to produce an iTunes playlist for my Mac laptop, which is what I use when travelling. Amusingly, the Mac version of iTunes won’t import an M3U, so I have to use the Windows version to convert to XML and then shove that on the Mac. Because of iTunes’ famed inability to do random play “properly”, I actually use a smart playlist (choose songs that are on this playlist and have been played less than n times) as an input to Party Shuffle to play this playlist.

And there it is. I rarely manually queue a track (the only one I can remember doing that to recently is Iggy Pop’s “Talking Snake”, which is a 9). I buy new music regularly – several CDs a month, which I listen to once and then abandon to their fate in my system. I don’t believe in choosing music to suit my mood. Perhaps I don’t have moods.

Anyway, if anyone’s interested, I could share the scripts. Comments and suggestions are welcome!

Share This

The Open Rights Group released its report on e-counting and e-voting in the recent elections. Executive summary: it didn’t work very well.

Incidentally, ORG is looking for board members, as some of the incumbents (e.g. me) are moving over to the Advisory Board. The deadline is June 22nd.

Share This

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.

Share This