[OpenID] Community Opinion on OID 2.1 Discovery and Identifiers...

David Fuelling sappenin at gmail.com
Sun Jun 7 20:01:25 UTC 2009


John,

I'm wondering if XRD might take care of some of the issues you
outlined....see my replies inline.

Thanks!

On Sun, Jun 7, 2009 at 6:54 PM, John Bradley <john.bradley at wingaa.com>wrote:

> The conflict between URLs and XRI has more to do with having multiple names
> that resolve to a single claimed_id where with URLs there is a one to one
> relationship.    I believe it was that impedance mismatch more than library
> complexity that prevented people from seeing any advantage to XRI.  The two
> identifier types also have different approaches to identifier recycling, and
> portability.  We need a single model and then fit the identifiers to it
> rather than trying to adapt the core to the identifiers in
> a piecemeal fashion.
>

Do you think using XRD might overcome this issue with respect to URL's? For
example, XRD defines a canonical-id, and allows for "many" aliases.  It
would appear that a person could have a single, "canonical-url", and then
have multiple other vanity urls.  When XRD Discovery is performed on the
vanity URL, the XRD document that is returned could list the canonical URL
as the "canonical URL" in the document.  It would seem to be a way to
simulate many-to-many using URL's.


>
> The first questions we need to answer:
> 1.  Are we going to support many to one relationships,  or enforce a one to
> one relationship?
>

See above.


> 2. Are we going to support identifier portability?
>

In the context of URL's, what does it look like to support identifier
portability?

At first I immediately thought of a vanity domain, which I could easily
"port" to a different OP.  However, I assume you're talking about the idea
where I have an "identity" at google, using a google domain, and then I want
to move this identity over to Facebook. (?).  With XRI (and i-numbers) this
might be trivial -- I just keep the same i-number...but in a URL-world, this
isn't really possible today.

However, with XRD it might be enabled by simply having Google forward any
XRD requests for my google-id over to Facebook, so anybody requesting my "
david.google.com" XRD get it, and notice that the canonical id is now "
david.facebook.com".  I'm not sure what the ramifications of a changing
"canonical-id" are (sort of seems like an oxy-moron) but it seems like it
could work to have the canonical-id be multi-dimensional -- i.e., it might
change over time.

Of course, Google/Facebook would have to play along with this type of thing,
and not recycle my identifier once I "move on".


> 3.  Are we going to decouple the display ID from the primary key?
>
>
Does this need to be specified in the core spec?  First of all, there's one
arguement to be made that OP's and RP's should have this authority (to
display whatever they want for you).  However, there's a couter-arguement
that says the user should determine what should be displayed.

Regardless of which side one takes in this arguement, I think this should
simply be specified as part of AX.  It's really not part of a core
authentication protocol.  Instead, "displayName" is really an attribute that
I'd like to define, potentially even on a case-by-case basis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090607/cf961af4/attachment.htm>


More information about the general mailing list