[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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+xml& 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=application/ 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]