Re: [xri] URIMap element (was: XRD trusted discovery workflow)

[Eran Hammer-Lahav <eran@hueniverse.com>]

Title: Re: [xri] URIMap element (was: XRD trusted discovery workflow)

This is actually a lot simpler than that.

When a user tries to sign-in using an OpenID identifier, what the user is typing (or choosing via a UI) is a URI of a resource which has a relationship to its IDP. Defining the OpenID URI as the ‘identifier of the user’ goes beyond what OpenID should be doing. We should not be in the business of assigning URI to people. We should be in the business of attaching useful information to a resource in the form of a link that can allow an application to extract value from it.

So in the current OpenID architecture, it does not matter WHAT the entered URI is identifying. All that matters is that an RP can find a link from that resource (via one of the three methods described in my flow overview email) to another resource capable of speaking the OpenID protocol. So my interpretation of an OpenID URI is: a resource linked to other useful SSO resources. It is out of scope what the semantic meaning of the resource in that context.

What is broken is the overloading of individual delegation and directed identity into a single mechanism. It is broken because there is no way to know (today) what they user intention was when they entered a URI (claimed identifier or directed identity). Because of that, it is not possible (today) to perform a different flow based on the user intentions. Semantically, directed identity should be performed on the ‘abstract site’ concept (suggest via a Link in /site-meta), which a claimed identifier discovery should be performed on the actual URI.

EHL


On 12/15/08 2:07 PM, "John Bradley" <jbradley@mac.com> wrote:

> We went around the block a number of times with the W3C TAG on this.
>
> Yes the use of openID URI to describe a abstract resource (the user) and return a 200 for a concrete resource (a blog page) is counter to AWWW.
>
> If the URI Returns a 303 it can then use content negotiation along with link headers to direct the client to the desired resource.
> The important thing is that the resource URI for the meta-data/XRD is  distinct from the resource URI for the blog etc.
>
> It would be true to say we have the same problem for user openIDs in that the XRD for http://thread-safe.net that is referred to in the link header at http://thread-safe.net should really be about the named resource which is a blog not me who some people refer to as a non-information resource.
>
> To be AWWW compliant a openID should resolve to a 303 that may redirect to a blog or other resource based on content negotiation or inspection of the link headers.
>
> That is fundamentally the approach we took with XRI.  In XRI all identifiers are abstract and with a small change will be AWWW clean.
>
> I have a hard time seeing openID changing its existing discovery.  Being semantic web compliant is not a high priority.
>
> Eran are you thinking that another way around the problem would be to always use site-meta when you want to resolve the abstract resource,  google.com , thread-safe.com even myopenid.net/ve7jtb ?
>
> If that is where you are going it is almost defining a third mechanism for CoolURI resolution.
>
> I wonder if using link headers you could legitimately have one relationship for the concrete 200 resource and another for the non-information resource that URI may be overloaded with.   Would that be a Coolish URI?  A 200 response and a link header saying the resource I returned you is really this other Resource URI not the one you asked for.  Sort of a high performance 303 redirect.
>
> I have a bad feeling the sem-web people will be putting a price on my head for that idea.
>
> Regards
> =jbradley
>
> On 15-Dec-08, at 6:15 PM, Eran Hammer-Lahav wrote:
>
> >  The scope of XRD is currently limited to describing resources. Resources are those identified with a URI. “Sites” do not have a URI.
> >  
> >  http://google.com/ isn’t a “site”, it is a very specific resource that returns a 200 responses. But “Google” is a site with the authority name “google.com”. The resource (http://google.com/) and the site (google.com) are not the same thing.
> >  
> >  Semantically, these two are not the same:
> >  
> >  ---
> >  
> >  GET /site-meta
> >  
> >  (response body)
> >  Link: <http://google.com/xrd/descriptor.xrd>; rel=”describedby”; type=”application/xrd+xml”
> >  
> >  ---
> >  
> >  GET /
> >  
> >  (response header)
> >  Link: <http://google.com/xrd/descriptor.xrd>; rel=”describedby”; type=”application/xrd+xml”
> >  
> >  ---
> >  
> >  The first provide the XRD for the abstract “site” concept while the second provide the XRD for the root resource. OpenID currently abuses the second to mean the first because /site-meta did not exists when Yadis was created. But the two are very much different. The right approach is to separate directed identity (using the site XRD) from normal individual identifiers (using the resource XRD) in the OpenID discovery flow, but this will break current implementations as there is no actual way of knowing if the user intended to type an actual identifier or directed identity.
> >  
> >  I consider the current design a bug.
> >  
> >  EHL
> >  
> >  
> >  On 12/12/08 4:02 PM, "David Fuelling" <david.fuelling@cordance.net> wrote:
> >  
> >  
> > > On Fri, Dec 12, 2008 at 10:05 PM, Dirk Balfanz <balfanz@google.com> wrote:
> > >  
> > > >  I guess what's rubbing me the wrong way here is that control over one URI's metadata (http://www.example.com/user/bob <http://www.openid.com/user=%7BURI%7D> ) is distributed all over the place, instead of being held close to that URI, where the owner of the URI has a chance to keep track of the URI's metadata.
> > > >  
> > > >  
> > >
> > >  Agreed.  The more I think about it, the more I agree with Drummond's take-away that started this thread.  We should use both options (site-wide delegation, with or without URIMap) as well as individual service delegation (with or without URIMap), with site-wide XRD delegation taking precedence.
> > >   
> > >  In that world, it seems like I would have ultimate freedom.  I could fully delegate a domain's root XRD for site-wide services, maintaining all XRD info (mostly) in one place, yet provide users with the opportunity to indicate service-level meta-data anywhere they like.
> > >  
> > >  
> >  
> >