OpenID, YADIS and Directed Identity
mgraves at verisign.com
Sun Feb 12 15:48:51 UTC 2006
I post this at the risk of having Johannes send out a special ops team to hunt
me down for throwing out issues like this at the (pregnant) point we're at with
In recent discussions about URL-based identity -- particular with a couple of
people from Microsoft who were (predictably) holding Kim Cameron's
"Seven Laws" over my head, it has become clear that while directed identities
are supportable in OpenID, a simple change in the semantics would allow elegant
integration of directed identities into OpenID servers and relying parties.
Also, I should note that Dick Hardt of Sxip correctly identifies this as a
deficiency in the OpenID/YADIS/LID mix right now.
I am not suggesting we stop and change anything in YADIS. Repeat, no changes in
YADIS. However, I would like this group to be thinking about how these proposed
changes might be integrated.
Just a quick summary of the issue for any who might not be familiar with the
term (you're familiar with concept):
If we think of a blog URL as being the *omnidirectional* identitier -- it is
how the blog is identifieed to all -- sometimes we want to use a *directional*
identifier -- an ID that is specific to a relationship. For example, I may have
an ID that Amazon.com knows me by, and another different ID that Expedia.com
knows me by. This is useful for me if I'm concerned about my privacy and want
to prevent *correlation*, a case in which Amazon and Expedia compare notes and
can each glean additional information about me by filling in the pieces the
other is missing.
For URL-based identity systems, then, directed identities are URLs that are
created on a per-instance basis just for a particular trust relationship.
Directed IDs *can* and do work with OpenID right now -- setting aside for the
moment that correlation is of limited value with OpenID since OpenID doesn't
support profile exchange (the correlated info would have to be gathered
separately). If I want to have, say Zooomr.com know me by a *dedicated* ID, I
could go to a capable identity server, and manufacture an alias. For instance,
if my identity server is "idsrus.com", I might add an alias for my "normal"
account ("mgraves.idsrus.com") that is just known between Zooomr and I
If I create this "alias" ahead of time, everything works fine. When I go to
Zooomr.com, I login as "343992.idrus.com". Voila! Directed identity.
So the OpenID/YADIS/LID mix *does* support directed identity, it just isn't
very convenient for the user: the user must prepare ahead of time, and create
the required alias that must be remembered or copy/pasted at the relying party,
instead of the normal URL. Not very elegant in terms of ergonomics, that.
Sxip has a much more elegant approach to this: Login with your "homesite" on
the front end of the process, and the identity server will return the selected
identity for this user as an output of the process.
In my example above, then, if we were to use the Sxip idiom, I would go to
Zoomr and login in as "idsrus.com", which isn't really logging in, but simply
redirecting to my identity server, where I can authenicate if needed, but then
also manufacture an alias for "directed identity" on the fly. When I click
"Login" at Zooomr.com and it redirects me to my identity server, I am presented
with a choice: login using an *omnidirectional* ID (say my blog URL), or a
*directed* ID that it will make up right then and there and register as an
What would be need to support this? The only change that I can think of would
be that the relying party would not require the "input" login URL to be the
same as the "output" login URL. If I can start by entering "idsrus.com", then
choose one of a number of personae that I control, including a one-time persona
that I made up on the fly just for this login, as long as the OpenID (or insert
your favorite protocol here) consumer evaluates the *output* URL I think it all
works out. As it is, OpenID is expecting (cryptographically) a match on the
As things start to converge here this spring, I think its important to think
ahead a little bit as to how this group will address the need for *directed
identity*. Technically, we can assert that its supported, now, via preparation
and copy/paste. But if this is indeed a fundamental requirement (as per
Cameron's Fourth Law of Identity), it would be good to investigate what it
would take to support directed identities in an elegant way.
I read a comment from Johannes a while ago mentioning that he was already
working on directed identity in LID 2.0. Maybe he can comment here on how his
designs will unfold.
More information about the yadis