Re: [xri] questions about LRDD / OpenID

[Will Norris <will@willnorris.com>]

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.

[0]: http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-01.txt
[1]: http://www.ietf.org/internet-drafts/draft-hammer-discovery-02.txt


> 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:
>
> LRDD method 1: <LINK> element
> <LINK href="http://provider.example.org"; rel="
> http://openid.example.net/rel/provider";>
>
> LRDD method 2: Link: HTTP header
> Link: <http://provider.example.org>; rel="
> http://openid.example.net/rel/provider";
>
> LRDD method 3: /host-meta file with Link or Link-Pattern entry
> Link: <http://provider.example.org>; rel="
> http://openid.example.net/rel/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.