RE: [xri] Re: Why CID verification hierarchies follow Refs (was RE: [xri] Nested XRDS documents in Ref processing)

["Gabe Wachob" <gabe.wachob@amsoft.net>]

BTW, Drummond, I personally have always assumed that someone would have two
different URLs for two different namespaces (that is, with separate
canonical ID prefixes).

In fact, the way to do this is to have the URL *contain* the canonicalID
prefix that is associated with that chain:

E.G. For XRI's that are under the canonicalID hierarchy =!343242!4324 (yes
bad syntax):

http://xri.wachob.com/xriresolve/=!343242!4324/

And for those under =!1234!5678

http://xri.wachob.com/xriresolve/=!343242!5678/

In fact, I've written code that did this (many moons ago) as a proof of
concept. The code actually gets deployed under /xriresolve - the stuff after
the first path segment is passed through to the code as extra path info. The
code still does the lookups in the same way - it just has to rewrite the
canonicalID for the resulting item depending on the canonicalid prefix that
was presented in the extra-path part of the Authority Resolution service
endpoint.

This is super-simple stuff... 

	-Gabe

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Wednesday, October 03, 2007 1:33 PM
> To: xri@lists.oasis-open.org
> Cc: 'Kermit Snelson'; andy.dale@ootao.com
> Subject: RE: [xri] Re: Why CID verification hierarchies follow Refs (was
> RE: [xri] Nested XRDS documents in Ref processing)
> 
> Kermit,
> 
> Interestingly enough, I sent an offlist message to Les this morning
> arguing
> that CID verification had to go "one way or the other", i.e., to use your
> analogy, in a single XRDS, you could either verify an authority's
> "biological children", or its "adopted children" (via a Ref), but not
> both.
> 
> The "Redirect & Ref Processing: Revision #4" proposal currently at
> http://wiki.oasis-open.org/xri/XriCd02/RefProcessing, and specifically Ref
> Example #1, shows CanonicalID verification only of "biological children",
> i.e., once @a*b delegates using a Ref to @x*y, @x*y can only issued
> verifiable CanonicalIDs for its biological children.
> 
> Your proposal is to reverse that, and say that, when @x*y is delegated to
> via a Ref from @a*b, all of @x*y's biological children have been "adopted"
> by @a*b, and thus @x*y MUST hand out CanonicalIDs rooted in the @a*b
> hierarchy.
> 
> I realized when exchanging messages with Les this morning that there is a
> practical way for @x*y to do this, which is to maintain a separate HTTP(S)
> URI for its $auth*res service endpoint for answering @a*b resolution
> queries. (In talking with John about this, he calls it a "multi-homed XRI
> authority server".) What this means is that @x has really assigned its
> child
> *y to represent @a*b. Therefore @x knows that all resolution queries
> addressed to @x*y must be given CanonicalIDs in the @a*b hierarchy.
> 
> That makes sense. What I really like about this proposal is that it
> elimiates the problem Les has been complaining about all along, and that
> Victor referred to in his message: the lack of consistency between the
> CanonicalID verification chain and the XRD chain. Since this rule would
> now
> require that all XRDs that are children of *each other* (i.e., their
> parent
> is the previous XRD in the same XRDS, not in a nested XRDS), then
> CanonicalID verification would run directly between every parent/child
> relationship in this chain.
> 
> I just called Les to discuss it with him, and he explained that this is
> the
> way he's always looked at it: each XRDS is its own CanonicalID
> verification
> chain. For example in the Ref Example #1 currently at
> http://wiki.oasis-open.org/xri/XriCd02/RefProcessing, there is an "outer
> XRDS" that is the chain for @a*b*c, and an "inner XRDS" that is the chain
> for @x*y. Les feels each XRD in each XRDS needs to be child of its parent
> XRD. Your proposal does that.
> 
> Net net: I am persuaded that to make this change to
> http://wiki.oasis-open.org/xri/XriCd02/RefProcessing as Revision #5. I'll
> proceed with that later this afternoon unless there are any loud protests
> on
> the list. Again, we'll use tomorrow's TC telecon to reach FINAL consensus
> on
> this before committing it to ED06.
> 
> Thanks again for a wonderfully written and illustrated proposal. You shed
> a
> great deal of sunshine on what's been the last big R&R issue for us to
> close.
> 
> =Drummond
> 
> 
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Wednesday, October 03, 2007 11:42 AM
> > To: xri@lists.oasis-open.org
> > Cc: 'Kermit Snelson'; andy.dale@ootao.com
> > Subject: [xri] Re: Why CID verification hierarchies follow Refs (was RE:
> > [xri] Nested XRDS documents in Ref processing)
> >
> > I am forwarding the following email from Kermit Snelson, who's account
> is
> > still in process at OASIS. He brings up some great points. I urge
> everyone
> > to read and ponder this and post your own thoughts about Kermit's
> > proposal.
> > Again, our goal is to reach final closure on R&R processing on
> tomorrow's
> > telecon (10AM PT) so we can lock down ED06.
> >
> > =Drummond
> >
> > -----Original Message-----
> > From: kermit.snelson@gmail.com [mailto:kermit.snelson@gmail.com] On
> Behalf
> > Of Kermit Snelson
> > Sent: Wednesday, October 03, 2007 11:28 AM
> > To: Drummond Reed
> > Cc: Chasen, Les; steven.churchill@xdi.org; jbradley@cogneto.com;
> > andy.dale@ootao.com; Victor Grey
> > Subject: Re: [xri] Re: Why CID verification hierarchies follow Refs (was
> > RE:
> > [xri] Nested XRDS documents in Ref processing)
> >
> > Drummond,
> >
> > I think "Redirect & Ref Processing: Revision #4" is great. In
> > particular, I like your proposals to allow Ref (and now also Redirect)
> > at the XRD level, and to restore the original XRD/XRDS nesting.
> >
> > After considerable cooking, however, I do find that I disagree with
> > the following statement in Section 6.5, "Synonym Verification":
> >
> > "During XRI authority resolution, the CanonicalID for an XRD following
> > the nested XRDS document resulting from a Ref MUST be a direct child
> > of the CanonicalID in the final XRD in the nested XRDS docment."
> >
> > A real-world analogue of this statement would be to say that
> > biological children can't be legally adopted. But why should adoption
> > be illegal, either of children or subsegments?
> >
> > To illustrate this argument, I've put together some working examples
> > that may be resolved and viewed using barx.
> >
> > Suppose we have two distinct authorities, each with its own CanonicalID:
> >
> > =kermit*adoptive (CanonicalID =!B7BD.2A1D.1040.58CD!1000)
> > =kermit*biological (CanonicalID =!B7BD.2A1D.1040.58CD!2000)
> >
> > =kermit*biological can have natural children (i.e., has an authority
> > resolution service):
> >
> >
> http://subjectivity.com:4000/=kermit*biological?_xrd_r=application/xrds+xm
> > l&
> > demo=true
> >
> > but =kermit*adoptive cannot (i.e., has no authority resolution service
> > of its own): So, =kermit*adoptive uses a Ref to adopt all the natural
> > children of =kermit*biological:
> >
> >
> http://subjectivity.com:4000/=kermit*adoptive?_xrd_r=application/xrds+xml&;
> > de
> > mo=true
> >
> > In turn, =kermit*biological indicates its agreement to this
> > transaction by serving up its biological children with CanonicalID's
> > rooted in =kermit*adoptive's CanonicalD rather than in its own. The
> > result is that =kermit*adoptive*children resolves successfully with
> > valid CanonicalIDs, which indicates that =kermit*adoptive now has
> > children that are legally its own (with an inserted XRDS to indicate
> > that its parentage is via legal contract, not natural):
> >
> >
> http://subjectivity.com:4000/=kermit*adoptive*children?_xrd_r=application/
> > xr
> > ds+xml&demo=true
> >
> > On the other hand, resolving =kermit*biological*children still works
> > (once a biological child, always a biological child), but CanonicalID
> > now fails. This is perfectly legitimate because this authority's
> > physical children are no longer its own legally:
> >
> >
> http://subjectivity.com:4000/=kermit*biological*children?_xrd_r=applicatio
> > n/
> > xrds+xml&demo=true
> >
> > So to summarize:
> >
> > 1) I can think of valid use cases that call for an authority service
> > to put its subsegments "up for adoption," i.e., to serve up
> > subsegments with CanonicalID's rooted in somebody else's hierarchy.
> >
> > 2) There's no spoofing problem because to accomplish this with
> > successful CanonicalID verification on =kermit*adoptive*children
> > requires consent of both parties: the first to Ref to the second, the
> > other to serve up CanonicalID's rooted in the authority of the first.
> >
> > 3) CanonicalID verification in this scenario functions exactly as
> > intended and in a logically consistent way. In all cases, CanonicalID
> > verification works simply by comparing the CID of each XRD with that
> > of the previous XRD at the same level. There is no need for special
> > logic, as in the Revision #4 proposal, that calls for "dipping into"
> > the final XRD of a nested XRDS in order to make CanonicalID
> > verification work for both resolution chains.
> >
> > This counterproposal does mean that CanonicalID validation will fail
> > in the case of =kermit*biological*children, but that is perfectly
> > legitimate. It simply indicates that =kermit*biological's children are
> > its own physically, but not legally.
> >
> > In fact, I'll go more general and suggest that this counterproposal is
> > necessary to preserve the integrity of CanonicalID verification as the
> > Social Web analogue of the legal concept of "title" as evidence of
> > ownership, possession, or custody. Just as in the real world, "title"
> > should be both transferable and exclusive, meaning that CanonicalID
> > verification should succeed in only one resolution chain at a time,
> > and that this right of "success" should be freely transferable from
> > one resolution chain to another if both authorities consent. Under the
> > Revision #4 proposal, CanonicalID verification success is neither
> > transferable nor exclusive; what I am proposing would, I think, fix
> > this.
> >
> > By the way, Drummond, I didn't copy the XRI list on this contribution
> > because I can't yet post to it; OASIS hasn't yet acted on my
> > membership application. If you'd like to forward this to the list,
> > however, please feel free to do so.
> >
> > =Kermit