XRI resolution questions from Victor and Kermit

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

Following are a set of questions developed by Victor Grey and Kermit Snelson
from their work on the rxripr (Ruby XRI Proxy Resolver) that we will discuss
on today's telecon.

=Drummond 

-----Original Message-----
From: Victor Grey [mailto:victor@2idi.com] 
Sent: Wednesday, September 19, 2007 2:09 PM
To: Drummond Reed
Cc: Kermit Snelson
Subject: XRI res questions

Hi Drummond,

Kermit and I had a productive working session on rxripr yesterday,  
which left us with a few questions for you:

1. Let's assume that an authority resolution request is made with  
ref=false and cid=true. If there were Refs that were not followed  
because of that, we should return a <Status> of "101 -  
REF_NOT_FOLLOWED", but if we verified the CID we should return a  
<Status> of "110 - CID_VERIFIED". How can we indicate both? And of  
course, all the permutations of that scenario.

2. In https trusted resolution, we are reading the spec to say that  
in order to use a $res*auth type service, the Service element has to  
BOTH have an HTTPS URI, and contain an element exactly like this:
<MediaType>application/xrds+xml;https=true</MediaType>

Have we got that right?

3. If we are not supporting SAML at this time, and we receive a  
request with saml=true, my take on it is that rather than attempting  
to do -any- resolution, we should immediately return an XRDS that  
looks like this:

<XRDS xmlns="xri://$xrds" ref="xri://=example">
<XRD xmlns="xri://$xrd*($v*2.0)" version="2.0" >
<Query>*example</Query>
<Status code="201">NOT_IMPLEMENTED</Status>
</XRD>
</XRDS>

Also, is it within spec when returning a 201 to change the text  
message to something more informative, like "SAML_NOT_IMPLEMENTED" ?

4. When attempting to satisfy an "https=true" authority resolution  
request, if we find no $res*auth service at all, but there is a <Ref>  
element, should we follow that to see if it is trusted-res compliant?

How about if we do find a $res*auth service, but it is not trusted- 
res compliant, and there is a <Ref> element? Having failed trusted- 
res on the Service elements, do we then report a 231 error, or do we  
follow the Ref to see if it can provide a trusted-res resolution path?

Also, how about if there is a $res*auth service, and it either is  
missing an HTTPS URI, or is missing the correct <MediaType> element,  
or both, and has a <Ref> inside the <Service> element. Do we follow  
the Ref or fail right then?

5. We think the spec should say that when following Refs, the  
implementation SHOULD check to see that each URI it follows is  
unique. Otherwise there is a security vulnerability where an attacker  
could create a denial of service condition by putting up an XRD that  
produces a circular reference (i.e. an infinite loop).

6. And last but not least, having followed one or more Refs, and  
having put together a final XRDS that contains other XRDSes, what  
does that do to CID verification? I assume that CID verification  
should only examine the chain of XRDs relating to the original set of  
XRI subsegments, and not look inside the enveloped XRDS -- is that  
correct?

Thanks!
=vg