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)


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> 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.




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