OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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




On Fri, Dec 12, 2008 at 1:46 PM, David Fuelling <david.fuelling@cordance.net> wrote:
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 

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:

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.

So this means that example.com's users would have to go to openid.com and tell _it_ where their real OpenID endpoint is (so as to enable openid.com to server proper 302s to the right places). When example.com's admin decides to switch providers from openid.com to idsRus.com, all the users would have to go over to idsRus.com and now tell that site where their OpenID provider is. And if idsRus.com doesn't offer this service (per-user choice of OpenID provider), then users are just out of luck.

I guess what's rubbing me the wrong way here is that control over one URI's metadata (http://www.example.com/user/bob) 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.

Of course, the other option - to put a resource map for a URI's that points to _that URI's XRD_ also has its problems, as I pointed out. 

Dirk.


Dirk.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]