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 Mon, Dec 15, 2008 at 1:55 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
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.

Actually, that was not what I was trying to say. I was merely using site-meta-ish syntax to describe options that we were pondering, in fact, for XRD (under the assumption that site-meta and XRD would be equally expressive): I was assuming that if /site-meta has a Link-Template option, then so will XRD (especially since those Link-Templates are where delegation happens, and we can't sign /site-meta).

But looking at your previous email again, this is probably where we were talking past each other:

On 15-Dec-08, at 6:15 PM, Eran Hammer-Lahav wrote:
> The scope of XRD is currently limited to describing resources. Resources are those identified
> with a URI. "Sites" do not have a URI.
 
If "sites" don't have a URI, and XRDs are for things that have URIs, then XRDs are not for sites? Does that mean site-specific meta-data (as opposed to resource-specific meta-data) _has_ to go into /site-meta?

I thought I could do something like this:

GET /site-meta

(response body)
Link: <http://google.com/xrd/descriptor.xrd>; rel="describedby"; type="application/xrd+xml"

Doesn't this tell me that the XRD for the _site_ (which is not a resource, since it doesn't have a URI) is at http://google.com/xrd/descriptor.xrd? So I could put site-wide meta-data (such as OpenID information about directed-identity flows) in that XRD, no?

If this was a wrong assumption of mine (and site-wide meta data such as OpenID server URIs _have_ to go into /site-meta) then, as Brian points out in another thread, we have a problem with secure discovery. For secure discovery to work, we either need to be able to sign /site-meta, or alternatively need the same resource-mapping capabilities that site-meta has in XRD.

Dirk.



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]