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

[John Bradley]

Inline

On 7-Jun-09, at 4:01 PM, David Fuelling wrote:

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

It might if the core spec supports the notion.   It doesn't really at  
the moment.

The spec currently takes the CID from the XRDS (will be Subject in  
XRD)  and sends that in openid.claimed_id and openid.identity.
This removes the ability for the OP to know what the user input at the  
RP.

The OP authenticates the CID and returns a iNumber  in the assertion  
rather than the users iName for XRI.

In the email case the user would input there email or XMPP address and  
the discovery process would as a result of discovery send the XRD  
subject to the OP for authentication.

The RP gets back an assertion with some URL as the identifier that it  
then publishes as the users openID in posts etc.

The core openID protocol is tied to the notion that the openID is a  
URL that retrieves a resource that describes the user (Blog) and that  
that URL + a generational fragment is the primary key for the RP.

That the RP can remove the fragment and have a display ID for the user  
that makes some sense.

That broke down for XRI,  as it may for email and other ID types.

Yes I think XRD is a big part of the answer,  however the information  
needs to find its way to the consuming applications.

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

XRI was designed for portability from the beginning,  it will be  
harder to achieve with other identifier types.

Though I can see the value in a service that hosts XRD and provides a  
stable XRD subject over time.  A user could then point vendor provided  
ID's at that XRD and that XRD could in turn point to any number of  
services at any number of providers.

Using XRD's to publish public keys as Andrew Arnott mentioned a couple  
of days a go is also a possibility that could allow a RP to recognize  
multiple XRD as belonging to the same entity.

I don't think we should throw up our hands and say it is impossible.

>
> 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.
>
What I am referring to by display identifier is the normalized input  
identifier the user input or some other identifier that provably  
belongs to the user, without requiring that to be the claimed_id/ 
primary key for the RP.    I think this needs to be part of the core.

> 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.
>
A user nicname or other ID that is not provably globally unique for  
the user should be part of AX.

John B.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090607/f2722092/attachment.htm>