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

[Eran Hammer-Lahav <eran@hueniverse.com>]

> From: Dirk Balfanz [mailto:balfanz@google.com]
> Sent: Monday, December 15, 2008 6:04 PM
>
> "confusing" only if the XRD is about a resource identified by a URI? Or
> "confusing" in general? (and, yes, those snippets were supposed to be
> from an XRD-for-a-site).

Not in the context of XRD for a site. It wasn't clear in your example and I wanted to demonstrate why the context is important when using these constructs.

> Does "confusing" mean you wouldn't want to see it in a spec?

Nothing you have suggested will be forbidden in the spec. My concerns are not about the XRD spec but how OpenID will use it.

> If site-meta doesn't have signatures, we might need both ("describedby"
> links in XRDs-for-URIs and in XRDs-for-sites).

Which is fine. But I think it will.

> I'm actually thinking it might be better for /site-meta not to have
> signatures. site-meta is supposed to be just like a (collection of)
> Link: HTTP header(s) (but for the site, not the root resource), and we
> can't sign those headers either. Plus, to do secure discovery of an
> authoritative XRD, the libraries parsing site-meta and the libraries
> parsing XRD would have to somehow work together to traverse the trust
> chain. Seems to be easier to say "trust is the job of XRD, not site-
> meta".

I don't think it will be part of the core spec, but the mechanism used (created) by XRD should be easy to apply to /site-meta. The beauty in the link architecture is that you can ignore links you don't care about. Simple clients can just ignore the rel="signature" link.

EHL