OpenID, YADIS and Directed Identity

[Michael Graves]

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 
YADIS...

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.

Directed Identity
===================
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 
("343992.idrus.com").

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 
alias.

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 
input URL.

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.

Thoughts?

-Mike