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


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]