OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xri] Redirect & Ref Processing: Revision #4

I think your confusion is well founded.  I believe that the REF's only
purpose is to find a SEP to an authority resolution service that can
answer for children of the QXRI (@a*b in this case).  Others seem to
think a delegation is occurring handing over name space control (@x*y in
this case).

So if the spec is going to say that a REF delegates control of authority
resolution making *c a child of @x*y then yes it should be under @x*y.
I, sounding like a broken record, think that *c is a child of @a*b and
should have a CID that is under the CID of @a*b.

- Les

> -----Original Message-----
> From: Victor Grey [mailto:victor@idcommons.org]
> Sent: Wednesday, October 03, 2007 1:56 PM
> To: xri@lists.oasis-open.org
> Cc: Markus Sabadello; John Bradley; Kermit Snelson; Andy Dale
> Subject: Re: [xri] Redirect & Ref Processing: Revision #4
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]