RE: [xri-editors] Trusted Resolution

["Wachob, Gabe" <gwachob@visa.com>]

Peter-
	You didn't mark it b], but I do like the use of HTTP Accept headers instead of modifying the URL. I like HTTP. Its got lots of useful features like this. 
	Is there any issue with this being a HTTP-specific solution? (of course, the use of HTTP URLs is a pretty HTTP-specific solution in the first place)..
	Also, does this complicate the resolution process at all? Are we imposing undue required functionality on the server or client that is going to create more burden for implementers? (I don't think so, but we should think it through).

	-Gabe

	 
__________________________________________________ 
gwachob@visa.com
Chief Systems Architect
Technology Strategies and Standards
Visa International 
Phone: +1.650.432.3696   Fax: +1.650.554.6817


> -----Original Message-----
> From: Davis, Peter [mailto:peter.davis@neustar.biz]
> Sent: Tuesday, November 16, 2004 2:36 PM
> To: Dave McAlpin
> Cc: Wachob, Gabe; xri-editors@lists.oasis-open.org
> Subject: RE: [xri-editors] Trusted Resolution
> 
> 
> On Fri, 2004-11-12 at 14:55, Dave McAlpin wrote:
> > Yes, I'm mostly waiting for review and feedback at this point.
> > 
> 
> I've been remiss in commenting on this...
> 
> a] I think there is nominal effort in adding client authN to this, and
> including it provides for some interesting 'closed' resolution
> architectures.  I'll draft a new section for client authN if 
> others feel
> the same way.
> 
> The signal for an authority to recognize a resolvers desire 
> for a signed
> (trusted)  response is proposed to be an additional name/value pair
> appended to the resolution request URI. I think i'd prefer seeing this
> as an http header element:
> 	GET /xri-resolve/.example
> 	If-Modified-Since: Fri, 31 Oct 2003 19:43:31 GMT
> 	Accept: application/xrids+xml
> 	etc...
> 	
> 	(note the 's')
> 
> this give the added benefit of allowing
> 	Accept: application/xrids+xml, application/xrid+xml;q=0.2
> 
> which allows content negotiation for authorities supporting both (in
> this case demonstrating an 80% weighted preference to xrids over xrid,
> but indicating that either would be understood by the HTTP Client). 
> HTTP response codes should be used when the requested mediatype is
> unavailable.
> 
> this approach also gives the server the ability to respond with a
> trusted reponse, if local policy requires this, and the 
> client expresses
> support for trusted res.
> 
> c] i'd like to see a mechanism whereby, in delegated models, the next
> signing key can be expressed by a names parent authority.  
> for example,
> resolving =example*foo, the XRID response to example would include an
> element <NextKey> of type ds:KeyInfoType (at least i think that's the
> type declaration)... this should also be bound to an XRIAuthorityID.  
> 
> --- peterd
> 
> 
> 
> 
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/xri-editors/membe
rs/leave_workgroup.php.