Is this ceremony too geeky?

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.

Published by

Kim Cameron

Work on identity.