Re: [xri] Delay in discovery spec

The most you can say about the URI that got you there is that they have directed you to that XRD.

Did they do it intentionally or by mistake is the question.

If the XRD claims to have a subject of http://example.com/jbradley#1234 and you confirm that by verifying example.cm's signature over the XRD or perform discovery on http://example.com/jbradley and retrieve the same XRD then you can reasonably believe that the subject of the XRD is what it claims to be.

I see the case of a blog say http://thread-safe.net having a link or a redirect and link to the XRD with the subject http://example.com/jbradley as beein relitivly common.

It is my blog so I may want to have it point to meta data about me. The subject/resource in this case me has a identifier http://example.com/jbradley#1234 my blog uri may be listed in the XRD as an alias I use or perhaps as a relationship of type blog or some such thing.

If the application doing the discovery wants to draw an inference that some URI that points to the XRD has a implied relationship with the XRD that is up to the App. That may be the case for openID where the person is proving that they know some secret that is verified by a OP pointed to by the XRD. But that is up to the application to verify not the discovery protocol itself.

On 2-Feb-09, at 9:13 PM, Eran Hammer-Lahav wrote:

Recent discussions with members of the TAG, as well as other feedback
pointed out various issues with redirections and other HTTP restrictions in
my spec. There are also significant differences between how the three
methods are applied.

For example, consider the case where an HTTP GET for URI X returns a 301.
The Link header approach will follow the redirect and get the header for the
next URI in line. Site-meta cannot do that and will produce (at best), the
Link-header equivalent of the 301 header... This is not good.

In other words, the discovery spec must not decide which representation is
more appropriate (the one on the 301 reply or the follow-up 200 reply). This
requires the introduction of a new Context URI concept (actually introduced
in the upcoming Link header draft).

The client must first figure out the URI associated with the most
appropriate representation it is interested in. So web browser can choose
this to be the 200 response after following redirection, while a semantic
web application can use the 301 response (or both).

After the appropriate representation is identified, the URI dereferenced to
obtained it should be the input in the discovery methods, and follow up
request can be made (not following redirects). Whatever we get for that URI
is *it*.

None of this changes how we were actually going to implement all the use
cases we discussed, but it changes a lot how I need to explain it. This is
my top priority this week and I hope to ship -02 tomorrow or Wed.

EHL

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

xri message