Day: July 12, 2005

Ben Laurie commented on my response to Doug Kaye's challenge with this:

This punts completely on a pile of issues that aren't obvious from your example. The top of my list are:

a) How do I know that Kim Cameron is the person who “signed” the release.

b) How do I know that Kim Cameron has anything to do with the event (that is, suppose (a) is satisfied, how do I tie that identity to the performance that is included in the event?)?

I think what Doug was looking for was a way to eliminate his liability from a content provider point of view. Thus the issue is not whether the real Kim Cameron is signing the release – it is whether the person speaking at the event has signed the release. Let's assume Darth Vader poses as Kim Cameron and speaks at the event. With the proposal we have outlined, Doug can be sure that Darth can't claim he didn't give approval to podscast his duplicitous public appearance. In this sense, the podcast stands.

The issue of whether Darth is Kim (or visa versa) is a matter of normal journalistic integrity, and concerns the relations between IT Conversations and its producers. It is a completely different question – potentially involving the identity metasystem but potentially involving a number of other brick and mortar approaches.

What I found so interesting about Doug's problem was that it was the identity of the event and its participants – as participants – which was at stake. The “context” was really unique.

Over at Blogarithms, Doug Kaye has a challenge for identity people:

Okay, all you identity gurus. (And I know you’re reading!) Here’s today’s challenge for you. For the new project we need to make sure we have authorization to record and publish tens of thousands of events every year from all over the world. How can we be reasonably certain that the person who gives us such permission is who they say they are and that they’re authorized to grant such permission?

It’s easy on the relatively small scale of IT Conversations. We have a written contract with each of the events we publish. But that’s not scalable worldwide and with the volume we anticipate.
I thought of one way we could do this, based upon the technique that Technorati uses to allow someone to claim an RSS feed. To demonstrate that the person has some association with an event, we could require that they add some invisible unique string to the HTML of one of the web pages associated with the event. We parse the HTML, find the secret string and close the authentication loop. The only problem is that we’re then limited to events with an on-line presence.

Got any better ideas for this one?

There are a number of good comments posted already. The difficulty here is that you have a number of parties involved who are collaborating (those being recorded as well as those doing the recording), and you require related releases from each of them with regard to some specific event.

In my view, Doug is – at the highest level – on the right track. Why? His scheme hinges on the identity of the event (it proxies this identity through the publisher of the web page tied to it). So I buy the high level approach.

However, there is another way to do it – this is part of some thinking I’ve done on related issues.

It would call upon the sixth law of identity – that the users of the system must be part of it, participating and understanding the system through a “ceremony”. Would it be possible to develop such a ceremony?

How about something like this:

1. Prior to a podcast, the “producer” runs a Podcast Ceremony Generator (C-Generator) on his workstation.

2. He enters the title and date.

3. The C-Generator creates four things:

• A private key available only to the producer.
• An event number which is a one-way function of the public key corresponding to the private key plus the date and title (example: X29 3BU 4PK).
• An html page containing a Podcast release script that can be read by the participants
• A record in the C-Generator database that remembers all this stuff.

4. During the mike check for the event, each participant reads the script. This is the ceremony. Here’s an example:

“This is [Kim Cameron] and I grant Scott Mace unlimited [blah blah] to distribute the event numbered X29 3BU 4PK, titled “Interview with Kim Cameron” and recorded on April 1, 2006.”

5. The producer records the participants reading the ceremony script. This is saved as the “Release” audio file.

6. The producer records the event, giving it the right title, event number, date and so on (for maximum protection this could even be part of the audio stream – for example in the closing credits).

“This has been “Interview with Kim Cameron” recorded on April 1, 2006, by Scott Mace with event number X29 3BU 4PK.”

7. After the event, the producer calls up the C-Generator, selects the title at issue, and drags in the Release audio file (recording of the ceremony script) so it will be available if ownership is ever contested.

8. When he wants Doug to post it, he types in the name of Doug’s organization (IT Conversations). C-Generator now produces an XML Release Blob signed by the private key that only the producer owns (and cryptographically related to the release number). He sends this and the podcast in to Doug (possibly the release audio file as well).

So at a high level, the steps are:

1. Produce the release script

2. Have the participants read it

3. Produce the release blob and send it to the publisher along with the program.

The system works this way. There is an event key, and the event number represents this key – along with the title and date – in human-speakable form. The participants sign this event key with their voices by reading it in the release ceremony. Then the producer signs the release with the secret that is provably at the basis of the event number.

The system is based on an algorithm that makes it intollerably expensive to search for keys that would, given a particular title and date, produce a given event number.

Finally, the system would work on web sites, or wherever.

Several readers have sent more information and details on the Belgian Identity Card program.

In a previous posting I said, “the use of government smart cards in establishing digital identity is optional and under the control of the person described.” Apparently my distinction between use of the card for digital identity and bricks and mortar identity wasn't at all obvious, so let me try again.

Belgians who have reached the age of 12 are obliged to carry an ID-Card. In the past this has been a paper ID Card. It is now being replaced by a smart card. It will remain mandatory that citizens carry this identification card.

Twelve-year-olds get a new (smart) card right away. Others in the population already have cards that are valid for ten years. What happens when they expire?

• You get an invitation letter from your municipality.
• You go to the municipality with your old card and the letter.
• You fill in a form, and sign it manually to assert that the data on the form is accurate. You add a picture, and pay between zero and fifteen euros, depending on the municipality.
• A few weeks later you get a letter with a “PUK” and a “PIN Code”, and the request to pick up your new card.
• When you pick up your card, you are asked whether you wish to “activate” it (there is basically an opt-out procedure).
• You use your PUK to activate it.
• You may change your PIN.
• You are done.

Thus, citizens can opt out of using their cards for digital identity purposes. They can opt out in the sense of not activating their card. And if they do activate their card, they can still, if they feel so inclined, opt to use some other authentication mechanism when accessing eGovernment.

Citizens, government departments and businesses will have to be convinced to buy card readers before the eID cards can be used in a widespread way for digital purposes in consumer scenarios And sites will have to provide users with alternatives besides smart cards – at least during the time period when large portions of the population are not equipped with both the activated smart cards and readers.

So while it may be mandatory to carry the card for brick and mortar (physical) identification, we should be careful before making the assumption that the same level of coercion is easy to apply in the digital realm. To me this is a bit of an aha.

The law of user control and consent will continue to make the success of the system contingent on user acceptance – unless a number of draconian changes are made to current legislation.

This emphasizes again the need to see this kind of system as part of a continuum of potential underlying identity options, and indeed, part of an identity metasystem. If we could get the metasystem “out there”, relying parties could accept self-asserted identity starting on day one (certainly a lot better than passwords) and users could upgrade the strength of their authentication just by plugging in an identity provider which recognizes strong tokens like the eID card. We would see the emergence of identity providers that could do claims transformation to suppress the universal identifiers and constant public keys associated with today's eID cards and issue tokens containing minimal necessary information in accordance with laws two and four.

Get the usability and privacy aspects right, and make use of the government identity part of a wider set of identity choices, and end-users will probably come in droves. Especially if eGovernment allows citizens to save time by doing things on the computer which otherwise would require that they visit a government office.