RE: [xri] XRD Examples (and Trust)

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

See inline.

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Wednesday, June 17, 2009 12:59 PM
> To: XRI TC
> Subject: Re: [xri] XRD Examples (and Trust)
> 
> 
> On Jun 16, 2009, at 10:10 PM, Drummond Reed wrote:
> 
> >> It's worth noting that the only thing that *would* be of value is to
> >> have the first XRD assert the actual public key that should be used
> >> to
> >> verify the signature of the second XRD.  But that is introducing a
> >> whole other set of problems, and is *not* something I am actually
> >> proposing we do.
> >
> > What's ironic is that this scenario is exactly what the XRI
> > Resolution 2.0
> > specification already accomplished. 18 months ago. It enabled a
> > chain of XRD
> > documents to be used as a trust chain in addition to the option of
> > using
> > conventional certs and a CA-based trust chain.
> >
> > Since there is a great deal of interest, at least among the hard-
> > core XRI
> > and XDI community, in the XRD-based trust chain model, and all it
> > takes to
> > support it is the <XRD:TargetAuthority> element (which was the
> > <XRD:Service:ProviderID> element in XRI Resolution 2.0) and the
> > <ds:keyInfo>
> > element (that is already defined in XML dSig and exactly what was
> > used in
> > XRI Resolution 2.0), I see no reason to go backward and remove this
> > functionality.
> >
> > In short, XRD 1.0 can support both a conventional cert-based trust
> > chain (in
> > which case <XRD:TargetAuthority> is not needed) or an XRD-based
> > trust chain
> > (in which case <XRD:TargetAuthority> is needed).
> 
> Ah, wasn't aware that the XRI community was already doing this.  I
> have no problem with keeping it around in that case.  But since
> TargetAuthority only makes sense when doing XRD-based trust chaining,
> would it make sense to simply use ds:KeyInfo inside of the Link?  

Yes, that's where it was used in XRI Resolution 2.0 (only then the Link
element was called the <XRD:Service> element). See section 10.2.2.2 of:

	
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution-
V2.0-cd-03.html 

> I'm not sure if we can just cherry pick elements out of the DSig schema
> like that and reuse them in XRD, but I think it should be okay.  

We /know/ it's okay - that's what we did in XRI Resolution 2.0.

> Or at the very least, should TargetAuthority be renamed to something more
> descriptive and its type changed to base64Binary like ds:X509Data has?

I'm not sure I understand. <XRD:TargetAuthority> in XRD 1.0 would replace
<XRD:Service:ProviderID> in XRI Resolution 2.0. The element type would still
be anyURI. From XRI Resolution 2.0 section 4.2.2:

****** QUOTE ********

xrd:XRD/xrd:ProviderID

0 or 1 per xrd:XRD element. A unique identifier of type xs:anyURI for the
parent authority providing this XRD.  The value of this element MUST be a
persistent identifier. There MUST be negligible probability that the value
of this element will be assigned as an identifier to any other authority. It
is RECOMMENDED to use a fully persistent XRI as defined in [XRISyntax]. If a
URN [RFC2141] or other persistent identifer is used, it is RECOMMENDED to
express it as an XRI cross-reference as defined in [XRISyntax]. Note that
for XRI authority resolution, the authority identified by this element is
the parent authority (the provider of the current XRD), not the child
authority (the target of the current XRD). The latter is identified by the
xrd:XRD/xrd:Service/xrd:ProviderID element inside a authority resolution
service endpoint (see below).

***** ENDQUOTE *******

> 
> > I'm also not convinced that <XRD:TargetSubject>, while perhaps not
> > required,
> > is not still helpful for security reasons, but I need to think about
> > it some
> > more.
> 
> would love to hear a use-case for it... None of us on the call last
> week could come up with one.

Agreed - ball's in my court.

=Drummond