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)

XRD can describe any resource, even one without a URI such as the “site” concept. The only differentiator is an XRD is linked to the resource. If the resource has a URI, we use the workflow I described. /site-meta is really just a pretend HTTP header for the “site” (because there is no other place to stick that information – you can’t GET a “site”).

So it might help to think about /site-meta as the “HTTP header of the site” where “site” is an abstract concept and not the root resource.
Also, XRD is a format for describing resources and their links to other resources, so it can describe a “site” as well as resources identified with a URI.

The “correct” way OpenID should work (this is just a straw man to demonstrate my point):

* Claimed identifier can be any URI with an authority component
* Directed identity identifier can only be a domain name (no scheme, path, or anything other than a port-less authority)

The RP should clearly ask the user if they want to use a claimed identifier (tied to them and only them) or directed identity. If the first is selected, the workflow described in my overview is used. If the user wants to use directed identity, they enter the domain name (or select it) and the RP looks for a Link record in /site-meta (not a template) pointing to the “site” XRD. That XRD contains the directed identity information for the site.

OpenID today is so semantically broken that it makes this discussion overly confusing.

EHL


On 12/15/08 2:27 PM, "Dirk Balfanz" <balfanz@google.com> wrote:

> On Mon, Dec 15, 2008 at 1:55 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> > It is really an application specific question which is completely on the OpenID side. I don't think this is the right place to discuss it but I'll give you a general overview:
> >
> > Today OpenID defines 3 discovery methods: HTML elements, HTTP header/XRDS document, and XRI resolution. The flow proposal I posted only replaces the mechanism for the second method from Yadis to something new. Consider it merely a replacement for the X-XRDS-Location header, the <meta> HTML tag, and the use of Accept header.
> >
> > OpenID needs to define how the needed information is obtained from a URI. Currently, it is either inside the HTML representation of that URI, or in the XRDS document linked from the URI. Putting the HTML elements aside (my personal view is that they should be retired completely), the only location left for providing the OpenID configuration/information as an XRDS file.
> >
> > A new OpenID discovery flow can remove the need for an XRD document is the information is available elsewhere, and /site-meta is one such option. This seems to be what you are suggesting with the rel="openid-signon" approach. It suggests sticking that information directly into /site-meta instead of in a linked XRD document.
>
> Actually, that was not what I was trying to say. I was merely using site-meta-ish syntax to describe options that we were pondering, in fact, for XRD (under the assumption that site-meta and XRD would be equally expressive): I was assuming that if /site-meta has a Link-Template option, then so will XRD (especially since those Link-Templates are where delegation happens, and we can't sign /site-meta).
>
> But looking at your previous email again, this is probably where we were talking past each other:
>
> 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.
>  
> If "sites" don't have a URI, and XRDs are for things that have URIs, then XRDs are not for sites? Does that mean site-specific meta-data (as opposed to resource-specific meta-data) _has_ to go into /site-meta?
>
> I thought I could do something like this:
>
> GET /site-meta
>
> (response body)
> Link: <http://google.com/xrd/descriptor.xrd>; rel="describedby"; type="application/xrd+xml"
>
> Doesn't this tell me that the XRD for the _site_ (which is not a resource, since it doesn't have a URI) is at http://google.com/xrd/descriptor.xrd? So I could put site-wide meta-data (such as OpenID information about directed-identity flows) in that XRD, no?
>
> If this was a wrong assumption of mine (and site-wide meta data such as OpenID server URIs _have_ to go into /site-meta) then, as Brian points out in another thread, we have a problem with secure discovery. For secure discovery to work, we either need to be able to sign /site-meta, or alternatively need the same resource-mapping capabilities that site-meta has in XRD.
>
> Dirk.
>
>
> > The obvious downside to such approach is that there is not place to add other information about the endpoint where XRD is totally extensible.
> >
> > EHL
> >
> >
> >
> > On 12/15/08 1:40 PM, "Dirk Balfanz" <balfanz@google.com <http://balfanz@google.com> > wrote:
> >
> > > Hi Eran, 
> > >
> > > I think I understood that distinction coming in. How does that help us decide whether resource maps should only be allowed for rel="describedby", or whether they should be allowed for other things as well, such as rel="openid-signon"?
> > >
> > > Dirk.
> > >
> > > On Mon, Dec 15, 2008 at 1:15 PM, Eran Hammer-Lahav <eran@hueniverse.com <http://eran@hueniverse.com> > 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 <http://google.com>  <http://google.com> ". The resource (http://google.com/) and the site (google.com <http://google.com>  <http://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 <http://david.fuelling@cordance.net>  <http://david.fuelling@cordance.net> > wrote:
> > > >
> > > > > On Fri, Dec 12, 2008 at 10:05 PM, Dirk Balfanz <balfanz@google.com <http://balfanz@google.com>  <http://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.