Here’s an e-mail chain between Doug Kaye and I regarding a possible solution to his Indentity Challenge. I make heavy reference to Kim Cameron’s proposal:
Hi Doug,
After having read Kim Cameron’s proposal, I see that it is very similar to mine. It pushes some of the work around between parties, although I’m not sure which is more desirable.
Instead of the person reading a ceremony, they are typing the public key (also called unencrypted code, later) into a cell phone. At this point, the computer does some work to see if there is a matching private key (called encrypted code), and when there is, it plays some audio to identify that private key into the recording. The phone system could be written so that after the person types the key in, the response says “Please state your name after the tone…” [States Kim Cameron] “Please hold the phone’s speaker to the microphone”. “Kim Cameron, April 1st, 2006, ‘Interview with Kim Cameron’, beep-beep-boop…”, where beep-beep-boop represents the matching private key in audio form.
Now when the audio is sent to you, you have a system that parses the beginning of the recording for your special audio, including the private key. When it exists, you know you have permission granted.
The solution requires heavier machinery on the ITC end and lighter machinery on the recorder/ event owner’s end. It’s possible that this system would enable more impromptu recordings, since the only things necessary at the event are the microphone to record, a cell phone to communicate, and someone’s (preferably the speaker’s) knowledge of that event’s “public key”.
There are other cool things you can do with the phone idea, including verify when the event is actually being recorded.
Kim’s could be subverted just like mine, in that Scott Mace could run the C-Generator for the event and hand the readers the generated script. Tim could register the event and punch the public key into the cell phone. I think we’ve placed very similar trust in the same roles.
A couple notes on the assumptions of the model:
You have a degree of trust in the person recording the audio. They would be ITC’s delegates, essentially. Instead of a computer checking a website, where the computer represents ITC, and the website represents the event, it’s now a person who checks a person.
Tim is responsible for making sure that John has some whoofy (sp?) at the event. Some bozo (including Tim himself, if you don’t trust him) could still register the event, show up with the code, punch it into the phone, and be on their way. Ideally the person with the code should also be a person that can prove their identity, like a speaker or organizer.
Someone at the event must have a cell phone. It doesn’t need to be able to record audio—that’s what Tim is there for, to record.
On to the model:
Tim never has the code (unless he himself registered the event, perhaps under a different identity). I’m no legal expert, but I would assume your event recorders are going to enter some sort of contract with you making such behavior illegal. ITC only keeps an encrypted version of the code around, and the only person who knows the unencrypted version is the event’s registrar, John. After calling ITC and punching the code in, an encrypted version of the code is played over the phone’s speaker and recorded on the same system that the event will be recorded on. That encrypted tone is compared with the encrypted code you have for the event, and when they match, and Tim verifies that someone in charge at the conference entered the code, you’ve identified them.
It is a bit unwieldy—sticking a cell phone in front of a microphone. However, the cell phone is pretty darn ubiquitous and it allows the whole process to be automated on a level up from reciting contracts and filling out forms.
Thanks for listening,
/k
P.S. This e-mail will be available at my blog: http://www.kurtiss.org/blog/?q=node/17 and I will post a link to the comments of your Identity Challenge entry.
On 7/23/05, Doug Kaye
> Hi, Kurtiss.
>
> You can find the discussion at http://www.blogarithms.com/index.php/
> archives/2005/07/06/an-identity-challenge/
>
> I think it’s far too unwieldy. First of all, it’s not likely that Tim
> will have the capability to record audio from his cell phone, if he
> even has one.
>
> But there are also too many ways to subvert the system. What’s to
> keep Tim from doing the whole thing? He could get the code, do the
> phone thing, etc., and never involve John. So what has he proven?
>
> ...doug
>
> Doug Kaye, Executive Producer
> IT Conversations
> doug@rds.com
> v: 415.453.1400
>
>
> On Jul 22, 2005, at 8:32 PM, Kurtiss Hare wrote:
>
> > Hi Doug,
> >
> > I seem to have misplaced the link you mentioned in one of the ITC
> > updates regarding suggestions on your current identification system.
> > Wish I’d have seen any conversation taking place around the subject to
> > get an idea as to where my own sits.
> >
> > The way I see it, you want to place as few requirements on the person
> > giving permission on the web, the person giving permission at the
> > conference (hopefully one and the same), and the person recording the
> > audio. Here’s what I’ve got:
> >
> > John goes to www.itconversations.com and registers his event. You
> > give him a special code (say 5-10 numbers). Internally, you store an
> > encrypted version of those numbers.
> >
> > Tim, the recorder, gets to the event, and before they start, attempts
> > to locate John, or someone John has delegated to ensure permission to
> > record (perhaps the event’s speaker). Tim dials 1-800-itconversations
> > (or whatever) and asks John to enter the special code he received when
> > registering the event. The audio on the other end of the cell phone
> > plays a tone corresponding with the encrypted version of that code
> > into the recording.
> >
> > Now the recording has a clip of audio at the beginning to reliably
> > confess that someone at the conference (up to the recorder to
> > determine that person has any validity there) has registered and given
> > permission to record the event.
> >
> > It’s likely in need of evolution, so if you’ve got a pointer to
> > ongoing conversation, or have any questions, please let me know.
> >
> > Thanks for your hard work,
> > /k
> >
> > Kurtiss Hare
> >
>
>