RE: [xri-editors] Trusted Resolution

["Davis, Peter" <peter.davis@neustar.biz>]

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