Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Michael Graves <mgraves <at> verisign.com>
Subject: OpenID, YADIS and Directed Identity
Newsgroups: gmane.comp.web.openid.general
Date: Sunday 12th February 2006 15:48:51 UTC (over 11 years ago)
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
 
CD: 3ms