RE: [xri] Returning a complete XRDS in proxy resolution

Wil-

 

1) The GCS XRD should be composed by inserting the 
information that the proxy has for the GCS authority. In fact, in openxri proxy, 
that information is largely in the proxy.properties file already... In reality, 
root authorities need to publish information widely about themselves anyway, so 
I don't think this is a big issue. Note that the root authority information only 
needs to go to proxies, non-proxy-using clients, and clients wishing to perform 
SAML-trusted-authentication themselves. In short, clients using proxies don't 
need this root authority info - one of the major reasons to use proxies. 

 

2) I don't think this inconsistency (if it actually exists) 
is a problem. If a client is doing trusted resolution verification itself, it 
can either ignore the first XRD (corresponding to the root) and just use the 
information it has preconfigured for that root, or (if especially paranoid) 
perform some correlation between the preconfigured info it has for a 
trusted root and that first XRD. This correlation is not XML-comparison - it 
would only be a logical comparison (I suppose) that the key fields (e.g. the 
public key the root uses to sign resolution requests, and root authority's 
providerid, etc) are equivalent to what the client has preconfigured. 
Applications probably don't care which behavior for correlation is used -- they 
should be basically equivalent, and thus also basically equivalent with direct 
resolution by a client. Thus, I'm not sure where the issue lies... 

 

   -Gabe

 

 

  

  
  From: Tan, William 
  [mailto:] 
Sent: Friday, June 23, 2006 4:49 
  AM
To: Wachob, Gabe; 
Subject: RE: 
  [xri] Returning a complete XRDS in proxy resolution

  

  

  
Hi 
  Gabe,

  
 

  
I remember very 
  vaguely discussions about that. What you said makes sense, and I agree that 
  the proxy output should include the GCS XRD in its 
  output.

  
 

  
There are a few 
  issues though:

  
    
What should the GCS XRD be? Is 
    it the XRD configured in the resolver (used by the proxy)? What if the XRD 
    for a given GCS changes? Will the proxy “resolve” the GCS to get the XRD for 
    it? 
    
Doing so breaks the consistency 
    between direct resolution and proxy resolution. Currently, an application 
    that uses the resolver doesn’t care if the resolver got the XRDS from a 
    proxy or by direct resolution – the resulting XRDS will have the same 
    structure (same number of XRD’s). It’s not a big deal and can be dealt with 
    quite easily. 

  
 

  
I’m not sure if it 
  would be a trivial change in OpenXRI yet; we’ll need to see what changes are 
  made to the spec.

  
 

  

  
=wil (http://xri.net/=wil)

  
 

  
 

  

  

  

  
  

  
From: Wachob, 
  Gabe [mailto:] 
Sent: Friday, June 23, 2006 10:51 
  AM
To: 
  
Subject: [xri] Returning a complete XRDS 
  in proxy resolution

  
 

  

  
I have been playing with the 
  openxri 1.0.0 proxy code and noticed that when I request a full XRDS document 
  back, the first XRD inside does NOT correlate to the GCS character (e.g. "@"), 
  but rather to the first subsegment after the GCS. In an earlier draft of our 
  specs, we explicitly addressed this issue and the only sensical thing to do 
  was to include the XRD for the GCS authority (but only when doing proxy 
  resolution - this is one of the main differences with lookahead/recursive 
  resolution).

  

  
 

  

  
The openxri proxy seems NOT to 
  return an XRD for the GCS authority and this seems broken to me. I can't find 
  in the resolution text where this is spelled out so I understand why it was 
  implemented this way. However, I think an XRDS returned from proxy resolution 
  MUST include the GCS authority XRD so a client knows exactly which GCS 
  authority is the root (even if not doing trusted resolution). I'm assuming 
  this is a fairly trivial change to the openxri proxy 
  code.

  

  
 

  

  
I strongly suggest we add this 
  language explicilty in 7.6 (in addition to referring to the requirements of 
  4.2) for when a client is using XRI proxy resolvers. In addition, I think 
  we should add this requirement for section 6 (trusted resolution). While a 
  client doing trusted resolution verification already has to know about roots 
  it trusts (and therefore can do correlation with the root authority and the 
  first non-root-authority XRD), I think explicitness and parallelism to the 
  non-trusted mode are important. 

  

  
 

  

  
   
  -Gabe

  

__________________________________________________ 
  
 
Chief Systems 
  Architect 
  
Technical Innovation and 
  Standards Management
Visa 
  International 
  
Phone: 
  +1.650.432.3696   Fax: +1.650.554.6817