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)


Title: Re: [xri] URIMap element (was: XRD trusted discovery workflow)
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.

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> 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> 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> ". The resource (http://google.com/) and the site (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> > wrote:

On Fri, Dec 12, 2008 at 10:05 PM, Dirk Balfanz <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.





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