OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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]