RE: [xri-editors] Trusted Resolution

["Dave McAlpin" <Dave.McAlpin@epok.net>]

a] I've certainly encountered cases where I wished I had client
authentication on resolution requests, but I've avoided because DNS
doesn't have that concept and authentication in general is a can of
worms. I'd be interested in reading a draft.

b] I don't know enough to comment about HTTP headers, but I'll ask for
internal opinions at Epok and get back to you.

c] I don't follow. How does this differ from the current proposal, where
XRIAuthority contains an optional ds:KeyInfo element to convey the
signing key of the next authority?

> -----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
> 
> 
> 
> 
> 
>