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

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

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