Re: [xri] Redirect & Ref Processing: Revision #4

["Markus Sabadello" <markus.sabadello@xdi.org>]

Regarding the question, which identifier should be presented to the final service. I think this is easy, it should be the identifier you originally started to resolve (@a*b*c), no matter what Ref/Redirect jungle you had to go through to reach the service.

Here's a quote from the XDI.org Contact ISS (i-service specifications):

"The use of the append attribute for the URI element in a Contact Service Endpoint enables a different Contact Page to be displayed for each i-name (or i-number) that resolves to the same XRI authority. (...), Contact Service Providers SHOULD offer customers the option of displaying a different Contact Page for each i-name register to the same XRI authority"

I think this would no longer work properly if you appended @x*y*c instead of @a*b*c.

Markus

On 10/3/07, Victor Grey < victor@idcommons.org> wrote:

Drummond Reed wrote:
> As for your idea that a Redirect should result in an XRD being
> replaced vs. a nested XRDS document, I agree that would be okay
> too. I like the idea that the audit trail could be that resolver
> would add a "redirect" attribute to the XRD. We'd specify that this
> attribute would NOT be part of the XRD when validating a signature
> under SAML trusted res.
>
> That approach only works one level deep, though, i.e., if a
> Redirect lead to another Redirect (an admittedly corner case), the
> nested XRDS document approach can show all of them (each XRDS
> nested inside the previous), whereas the XRD replacement + redirect
> attribute case would only show one (unless we said you put all the
> redirect HTTP(S) URIs in the redirect attribute value, space-
> separated, which seems kind of clunky).
>
> What do others think?
There is (in my mind) a fundamental difference between following an
HTTP redirect and an XRD Redirect, at least when it comes to
authority resolution. Taking the example of @a*b*c where the XRD for
c, that was produced by b, asserts a Redirect:

Let's say that I trust the authority @a*b, so I am inclined to trust
the XRD data that @a*b produces when queried for c. But now, via a
Redirect element, c is going to take over from b and assert -its own-
XRD for -itself-.

I'm not saying that the spec should disallow this, only that what
happened should be obvious, so that policy decisions can be made
based on it. The nested XRDS works for me in that regard. I also
think there should be a redirect=boolean request parameter, so that a
relying party can choose to refuse a self-asserted XRD.

-------
Regarding the representation of Ref processing, the question I have
is what identifier is to be presented to the service that is the end
goal of the process? Let's say that I am resolving @a*b*c and b has a
$res*auth service for c containing a Ref to @x*y. At the end of the
process I'm going to get a final XRD with a set of services. Do I
make a request to service Z with the identifier "@x*y*c" (or its
canonicalID), or do I make the request with "@a*b*c"?

It seems to me that since I could have gotten to the -same resource-
on behalf of the -same party- by resolving either @a*b*c, or @x*y*c
directly, it would be more consistent to present @x*y*c to the
desired service in either case.

Which of these alternatives we choose should guide the way the result
is presented. If it's going to be @a*b*c, then it makes sense to show
the final XRD for c at the same level as a and b. If @x*y*c is what
should be presented to the chosen service, then the final XRD should
be at the level of the @x*y XRDS. The authority resolution example
that's on the wiki at this moment seems to straddle these choices in
a way that's really confusing (to me).

=vg