Thanks for the answers Will.. I think it would be very useful to write a generic LRDD library which you can feed a URI, and it will give you back all Links, and you don't have to care whether they come from a <LINK> element, a Link: header, a /host-meta file or an XRD. That library can then be used by OpenID, oAuth, etc. And then you don't have to ask the question "Does OpenID/oAuth/etc support the specific LRDD feature X?"
I'm just wondering if there isn't too much "It's application specific" in LRDD to be able to write such a generic library.
I'm certainly not Eran, but I'll take a crack at these...
On Mar 23, 2009, at 8:44 AM, Markus Sabadello wrote:
1. When performing LRDD on Joe's OpenID http://example.com/joe, you say that
in step 3 the relying party gets the /host-meta file and looks for the
"Link-Pattern" entry. My question is, shouldn't it also look for a "Link"
entry?
<snip>
yeah, absolutely... consumers should most certainly look for both Link and Link-Pattern. They are semantically equivalent. I assume that was just an oversite in Eran's post, not mentioning both elements.
2. In LRDD, if the /host-meta file contains both a suitable "Link" entry and
a suitable "Link-Pattern" entry, which one takes precedence?
It's application specific.
Quoting from draft-nottingham-site-meta-01 [0]:
> As with HTTP headers, field-names are not case-sensitive,
> unrecognised field-names SHOULD be silently ignored when parsing this
> format, and ordering of fields SHOULD NOT be considered significant
> unless specified otherwise.
Quoting from draft-hammer-discovery-02 [1]:
> Since a single resource can have many descriptors, the "describedby"
> link relation has a one-to-many structure (the question whether a
> single descriptor can describe multiple resources is outside the
> scope of this memo). In the case of multiple "describedby" links
> obtained from a single method, selecting which link to use is
> application-specific.
3. It seems that XRD is now very similar to the various Link mechanisms. My
question is, in your OpenID example, could the same goals be achieved
without using XRD at all? E.g. when performing LRDD on Joe's OpenID http://example.com/joe, instead of discovering an XRD via describedby links,
couldn't you also directly discover the OpenID provider:
Again, I'm not arguing whether this is good or bad, but I'm wondering if it
would work. Do you expect that LRDD / OpenID implementations will support
this?
If I understand your terminology correctly, this way you could jump directly
to "Service Discovery", omitting the "Descriptor Discovery" step.
Given that OpenID is already doing this with the <link> HTML element (though with non-URL rel values), and the Link header is intended to be semantically equivalent to the HTML element (yes?), I would assume we could most certainly expect to see this kind of thing. Of course, it would be have to be defined by some future OpenID Discovery spec.
To add one additional question... for the delegation use case, how is it expected that one would specify the OpenID delegate URL in XRD? I can't think of any existing XRD element that would be suitable for this, so I'm assuming we are expecting OpenID Discovery to define a new Link sub-element, like they already do in XRDS? Of course, if there is no delegate specified, you would just use the XRD Subject.