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

["Drummond Reed" <drummond.reed@cordance.net>]

Les, read Kermit's message that I just forwarded to the TC. He agrees with
your position. I need to think about this further and will post a reply
shortly.

=Drummond 

> -----Original Message-----
> From: Chasen, Les [mailto:les.chasen@neustar.biz]
> Sent: Wednesday, October 03, 2007 11:28 AM
> To: Victor Grey; xri@lists.oasis-open.org
> Cc: Markus Sabadello; John Bradley; Kermit Snelson; Andy Dale
> 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
> >
> >
> >