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

However, since we can't talk about delegation in /site-meta, or have any plans to sign it, there is also a need to have these resource maps in XRD, as that will be the mechanism through which authority is delegated in a trusted discovery flow.

What we were trying to figure out is the following, and I think I can frame the problem on the /site-meta level (with obvious translations into the XRD level, at which we were having this discussion):

What is the rel-type for resource maps?

Is there just one for XRD, as in

Link: template=http://www.example.com/xrd?uri={URI}; rel=xrd

(meaning "to get the XRD for http://www.example.com/user/bob you need to go to http://www.example.com/xrd?uri=http://www.example.com/user/bob"), or are there different rel-types for the different kind of meta-data clients might be searching for, for example:

The problem with the former is that it makes it harder to outsource, say, an OpenID endpoint for a whole domain. Let's say example.com wants to outsource their OpenID endpoint to openid.com. We want to make it as easy as possible to do that for example.com, preferably they would just serve a /site-meta with a simple link in it like this:

Link: template=http://www.openid.com/xrd?uri={URI}; rel=xrd

At this point, openid.com not only becomes example.com's openid provider, it also becomes their portable contacts provider, etc., whatever you may have in these XRD files. Now, openid.com could delegate portable contacts further - they could even provide a service where they allow example.com's users to do this on a per-user basis, but still this is not ideal - openid.com didn't ask to be in the business of managing users' general metadata, all they wanted to be was an OpenID provider.

So that leaves us with the second choice, which also has problems: example.com's /site-meta could say something like

At this point, we lose the ability for example.com's users to specify their own OpenID provider completely. The discovery algorithm looking for the OpenID endpoint (i.e.: metadata of type http://spec.openid.net/signon) for the URI http://www.example.com/user/bob would never get a chance to see the XRD document for that URI. Instead, example.com's admin essentially says "I decide where all my users's OpenID endpoints are" (and oh by the way I don't like portable contacts, so they don't get those at all).

That's the conundrum we're facing. Solution 1 (where resource maps can only point to other XRD documents) makes it hard to delegate two different services (say, OpenID and PoCo) to two different providers. Solution 2 (where resource maps can be specified for arbitrary rel-types) makes it impossible for sites to point to different, say, OpenID providers for different users (more generally, to have different metadata of type X for different URIs).

I'm not sure I was able to describe the problem well, but does this make sense?

On Thu, Dec 11, 2008 at 11:40 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Yes.

I wish I wasn't so distracted the past two days and available to offer my views on this (which are both based and directing the work on /site-meta and XRD), and maybe save you all this very long thread…

At the /site-meta level, there will be a facility to describe URI mapping via a URI template. /site-meta will have a canonical TEXT representation (Mark will hopefully push it out soon) instead of the current XML. XRD will define an XRD-based version of /site-meta so that a GET on /site-meta with Accept: application/xrd+xml will produce an XRD version of the same content (or just return the text format). At this level, templates will need some filtering based on the URI scheme.

The template element itself will need to support 2 attributes: vocabulary and syntax. This will allow any URI template format and any vocabulary. Within XRD, both can be implied from the <Rel> or <Type> of the <Link> (<Service>) but this is more true for vocabulary than syntax. I will send a full walkthrough tomorrow which will help understand how all this will work.

The most important take-away is that it doesn't matter what you start with (mailto, http, im, etc). /site-meta will map any URI to the HTTP URI of the descriptor. Once you get an XRD file, you continue the same way.

EHL

From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thursday, December 11, 2008 12:12 PM
To: xri@lists.oasis-open.org
Subject: [xri] URIMap element (was: XRD trusted discovery workflow)

My takeaway from the recent URIMap discussion is that there are two "levels" where we need URI mapping.

The first one is at the XRD level (the site-meta level). The use case here is, "I have URI X and I need to find the XRD for it." Finding that XRD can require requesting the site-meta file and then using it's URIMap to find the XRD (I understand site-meta may not be XML so it may not have a URIMap element, but it would be whatever the URI mapping equivalent is).

The second level is following a link from one XRD to a related resource. The use case here is, "I have the XRD for URI X and now I want the URI Z for the resource whose relation is Type Y". Computing URI Z from URI X can require a URIMap.

It seems that for the first level, the URIMap element should be in the /site-meta file (or the XRD that serves that role if we support that option).

For the second level, the URIMap element should be a child of <Service> (or <Link> if we call it that).

Do I have this right?

=Drummond

From: sappenin@gmail.com [mailto:sappenin@gmail.com] On Behalf Of David Fuelling
Sent: Thursday, December 11, 2008 11:36 AM
To: Dirk Balfanz
Cc: Brian Eaton; xri@lists.oasis-open.org
Subject: Re: [xri] XRD trusted discovery workflow

On Thu, Dec 11, 2008 at 7:10 PM, Dirk Balfanz <balfanz@google.com> wrote:

I do think that something like

<Service>
<Type>uri-to-uri-map</Type>
<URIMap>...</URIMap>
</Service>

doesn't make much sense b/c both the <Type> element _and_ the <URIMap> element say that this is a URI map. We don't need to say it twice.

I disagree. The <Type> describes the service (It's a way to map URI's, e.g.). The URIMap is the way you go about mapping the URI.

If you omit the <Type>, then how does an XRD consumer know that the URIMap is supposed to be used to map URI's to URL, instead of doing something with some other Service-Type, like OpenID.

As an example, these two Services are very different, despite having the same URIMap.

<Service>
<Type>http://xrd.something/GenericURIMap</Type>
<URIMap>http://example.com?uri={uri}</URIMap>
</Service>

and

<Service>
<Type>http://specs.openid.net/auth/2.0</Type>
<URIMap>http://example.com?uri={uri}</URIMap>
</Service>

xri message