[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]