Over here
somebody has been doing some reverse engineering of the TypeKey
authentication protocol. I want to pick that apart a bit since I think
this is going to spread fast once it’s released. It’s a good thing
for people to know what’s going on. There are things here I don’t approve
of.

This is a pretty typical cross site sign-on system; people have been
building stuff like this ever since browsers started to support
automatic redirect – so for a very long time in Internet time.

I find it helps when telling these stories to personify the players
a bit. We need three players in our little story:

• Victoria: The site that would like to authenticate a vistor.
• Fido: The visitor to that site. “On the Internet nobody knows your a dog.”
• Arthur: The authentication service. (Arthur’s an authority)

Well, maybe four because meanwhile off stage there is always Mr. Evil.

Victoria would like to trust Fido so she can let him put stuff on her
site. Victoria trusts Arthur to vouch for Fido. Fido has some light
weight relationship with Arthur that allows Arthur to assert that he
is actually dealing with Fido today.

These mechinisms work like the “letter of introduction” that travelers
used to bring with them when they traveled to a foriegn city. That
letter would introduce the young man, that’s Fido in our story, to somebody
reputable in the foriegn city, that’s Victoria in our story. The letter
would be written by somebody that Victoria knew and trusted, that’s Arthur
in our story.

This mechinism needs to get a letter of introduction to move from
Arthur via Fido to Victoria. We can do that with browser redirection.
When Fido shows up at Victoria’s site she bounces him over to Arthur’s
site and Arthur bounces him back with the “letter of introduction.”

That can all happen pretty quickly, and it doesn’t even need to
require any interaction with Fido. You can do it redirecting a small
embedded image so it’s pretty low impact on the user experiance. Of
course it might be polite to ask Fido before you do it.

Arthur, who wants to have a good relationship with Victoria and with
Fred, needs to be careful about the politeness thing. For example,
Fred’s not going to be pleased if Arthur starts introducing him to all
kinds of strangers. Understanding how to get systems like this to be
respectful of people’s privacy demands thinking thru the incentives
for the various parties as well as thinking about worse case scenarios.

In TypeKey the role of Authur is played by the folks at Six Apart who
make TypePad and MovableType. A lot of people, me included, think these
are good people.

Here’s is how the bounce is implemented. Victoria
bounces Fido over to Authur using a URL like this:

   https://www.typekey.com/t/typekey/login?t=<blog_token>&_return=<return_url>

This in effect says “Yo, Arthur? – You know this dude? – Victoria.”
or in this example it’s “Yo www.typekey.com? – You know this dude? –
<blog_token> <return_url>.” The return_url is where the Arthur should
reply to. Blog_token is very a very obscure thing
(e.g. “LjRd2DpifL51sB0iFeYT”, or “R234”), but it’s just Arthur’s pet
name for Victoria. That token is meaningless (opaque) it’s used only
in conversations between Arthur and Victoria.

   https://www.typekey.com/t/typekey/login?t=R234&_return=http://viki.com/http://viki.com/handler.cgi?a=_return

Arthur won’t answer these question from just anybody. He only answers it
for folks like Victoria he has a good relationship with. So that pet
name is important. Arthur’s going to look up the status of Victoria’s
relationship with him using that.

Before he replies he’s likely to do a couple things. For example he’s
likely to check if Fido is ok with this automatic authentication
bounce back thing. If Fido’s not approved that Arthur might tell
Victoria that she needs ask Fido to let down his privacy guard a bit.

Arthur is also responsible for being careful to check that he doesn’t
answer questions from Mr. Evil just because he happens to know the
Victoria’s pet name. One part of that is to only reply to a return_url
that has was explicitly registerd by Victoria.

Of course Arthur’s also going to check and see if this is Fido.
Recall that we are actually bouncing Fido’s web browser over to
Arthur; so Arthur can use cookies he left there to figure out if he
knows this dude or not.

Assuming Arthur can convince himself that this is Fido then he bounces
Fido’s browser back to Victoria using a URL that looks like this:

  <return_url>&ts=<timestamp>&email=<hashed_email>&name=<name>&nick=<display_name>&sig=<crypto_signature>

For example:

  http://viki.com/handler.cgi?a=_return&ts=1294252341&email=adg3adfa3&name=Fred&nick=Good+Dog&sig=vuXeBVRJG2cR4xl81+HoeJMbKYs=:DBASoTXIQtlxs07jRblTLRk=

I don’t think much of this reply’s design. Let’s pick it apart.

In the trade this reply is known as a “statement” or an “assertion.”
It is the letter of introduction of old. Like that letter it is
signed, by Arthur, so it’s recipient Victoria can know who is making this
statement.

The entire assertion should be encrypted, as it is the statement is
revealing things about Fido to folks listening in on the conversation
between Victor and Arthur. That’s just rude of the them. In the best
of worlds this would be sent using https. That would require that
Victoria have a https server. That’s a pain. But, if Victoria can
check that signature then she can probably decrypt the reply packed
into the message.

You can see what Arthur has decided to tell Victoria about Fido. Three
things: “name,” “nick,” and “email.”

I don’t know why it’s good to tell Victoria all this info about Fido.
The usual argument is people make for such revealing is that it allows
Victoria to fill out forms for Fido faster; giving him a more pleasing
user experiance. But shouldn’t that be up to Fido? In the example I’ve
shown above they have revealed that Arthur happened to know that Fido’s
name is Fred; and that he has used the nickname “Good Dog.”

I don’t see why that was any of Victoria’s business, since at this point
Fido and Victoria have just met and all Victoria needs to know is if it’s ok to allow Fido to post a comment on her blog.

The email address isn’t really an email address. It’s another bizzare
token: “adg3adfa3” (actually it was really:
“a4426c6a28b21941e3de8b14541e10e5aabb24e8”).

Most people’s first reaction to a jumble like that is “ok that’s safe.”
It’s a good habit to get into to then think. “I wonder what database
that might be a key into?” or “I wonder what message is encrypted in
that?”

In this case that’s the key for looking up what’s known as a FOAF file.
FOAF is the mnemonic for the cheerful sounding “Friend of a Friend” file.
Recall at this point that “cookie” sounds nice too; but that doesn’t
prevent them being used for evil.

Recalling out letter of introduction example the reason Arthur
included that in his reply to Victoria was similar to writing “If you
want to know more about my friend Fido, take a look here.

FOAF files are cool. For example
here’s a view of my
FOAF file. I decided to reveal the information you see there. Did I get permission from all those folks (my so called “friends”) in there to reveal their names? Nope. That was kind of rude of me.

That complex looking string is known as a “mbox_sha1sum”, it is based on an
email address, but let’s call it the foaf universal identifier. Or maybe we
should call it the universal id. Or maybe we should just call it the devil’s
mark. The problem is that one you know somebodies’ mbox_sha1sum you all
set to go looking for their FOAF file in any database that happens to have
it.

This is the same problem that arise if you have a national ID number. It
makes it far to easy for data about an individual to be sought out from
multiple sources. It far to likely that if a database of personal data is
leaked by mistake that Mr. Evil will be able to tie that data to other
data from other sources. It encourages identity theft.

Arthur and Victoria should create a private handle that they use to discuss
Fido. I notice that used just such a private handle when for Victoria
when they began their converastion about Fido; what I called a “pet name” above. One step in that direction would be to use a one off email address for Fido that Arthur gives him, that would help avoid revealing Fido’s personal information stored in other FOAF files. That would help a little.

But the fact is that Fido may want to reveal somethings to Victoria and other things to other folks. That requires an entirely private handle for Authurs discussions with Victoria about Fido. Without that is it possible for Victoria to trade private information about Fido with others who interact with Authur. That’s exactly the problem that cookies enabled. It’s what allows a company like double click to track your web browser as it travels over a set of sites of their clients to create a more complete model of you. But this is somewhat worse because Arthur has enabled the trading of information about Fido and he doesn’t any means to control the situation going forward.

There is one additional thing that bothers me about the TypeKey design.

But first I want to make perfectly clear that I believe that it is not practical to build useful authentication systems in the web without encouraging folks like Arthur appearing on the scene. Both Fido (aka Fred) and Victoria need trusted third parties to help make introductions and lubricate the flow of that information which they want to reveal. The design challenge is to be sure that we don’t encourage the emergance of a single Arthur. We want to encourage a huge number of them.

So the last thing, or maybe the first, that concerns me about the TypeKey design is that it lacks a mechnism to encourage more than one Arthur’s emergance. That’s not that hard. It just demand that when Victoria starts the conversation with Arthur she has a way to discover which Arthur(s) Fido would prefer that she use. She can then select one or more that she trusts and proceed from there. But, you got to get that right up front.

Other junk about identity that I’ve written.