Agreed, Gabe. That's how Kermit's examples work as well. It's just that none
of us were looking at the CanonicalID verification problem that way.
Another reason why many eyes makes for good specs ;-)
=Drummond
> -----Original Message-----
> From: Gabe Wachob [mailto:]
> Sent: Wednesday, October 03, 2007 1:48 PM
> To: 'Drummond Reed';
> Cc: 'Kermit Snelson';
> Subject: RE: [xri] Re: Why CID verification hierarchies follow Refs (was
> RE: [xri] Nested XRDS documents in Ref processing)
>
> 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:]
> > Sent: Wednesday, October 03, 2007 1:33 PM
> > To:
> > Cc: 'Kermit Snelson';
> > 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:]
> > > Sent: Wednesday, October 03, 2007 11:42 AM
> > > To:
> > > Cc: 'Kermit Snelson';
> > > 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: [mailto:] On
> > Behalf
> > > Of Kermit Snelson
> > > Sent: Wednesday, October 03, 2007 11:28 AM
> > > To: Drummond Reed
> > > Cc: Chasen, Les; ; ;
> > > ; 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
>
