[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]