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

["David Fuelling" <david.fuelling@cordance.net>]

On Fri, Dec 12, 2008 at 6:33 PM, Dirk Balfanz <balfanz@google.com> wrote:

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

Link: template=http://www.openid.com/user={URI}; rel=http://spec.openid.net/signon

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?

Dirk.

We had similar issues when designing EAUT, and overcame this problem by using http redirects (usually 302 redirects).  So, in your "second choice" example, the URI http://www.example.com/user/bob would bootstrap on example.com's /site-meta, yielding the following:

Link: template=http://www.openid.com/user={URI}; rel=http://spec.openid.net/signon

This translates into :

http://www.openid.com/user=http://www.example.com/user/bob

Resolving this URL could yield something actually served from the openid.com domain.  Alternatively, if openid.com wanted to let some other service provider handle OpenID, then resolving the openid.com link above could return a 302 redirect to any other URL, allowing openid.com to delegate however it wishes.