[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] ED04 synonym proposal (was RE: [xri] CID changes in wd11)
I agree with Les. It seems to me that we have the following: Ref - resolution semantics only EquivID - equivalence/synonymity semantics only (non-enforceable) MapToID - equivalence/synonymity semantics enforceable by resolution MapFromID - used as an explicit permission granting in order to support MapToID. A MapFromID will not be acted upon by the resolution client if it was not trying to verify a MapToID. It seems to me that EquivID is almost redundant, if one could express weak synonymity using a MapToID without the corresponding MapFromID. =wil Chasen, Les wrote: > > I do like the separation from existing attributes better. I am not > sure I see a strong enough reason for there to be an equivId and > MapToId. The proposal equates mapToId to an http 301 permanent > redirect. I am not sure that is a valid parallel to draw. There is > nothing in the proposal that makes the XRD that contains the mapToId > to not be used as one normally is used. > > > > contact: =les <http://xri.net/=les> > > voice: =les/(+phone) <http://xri.net/=les/%28+phone%29> > > chat: =les/skype/chat <http://xri.net/=les/skype/chat> > > pibb me =les/+pibb <http://xri.net/=les/+pibb> > > > > > > > > > > ------------------------------------------------------------------------ > > *From:* markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] > *On Behalf Of *Markus Sabadello > *Sent:* Saturday, August 18, 2007 4:27 PM > *To:* Drummond Reed > *Cc:* Gabe Wachob; Davis, Peter; Chasen, Les; William Barnhill; > steven.churchill@xdi.org; XRI TC; Andy Dale > *Subject:* Re: [xri] ED04 synonym proposal (was RE: [xri] CID changes > in wd11) > > > > > Having missed most of the TC call, I don't know what other peoples' > opinions are, but here's mine: > I like the EquivID, because it's easy to understand, has only one > meaning, and because it's symmetrical. The separation of "resolution > equivalence" (Ref) and "identification equivalence" (EquivID) sounds > very useful to me from a practical standpoint, although it would be > interesting to hear Steven's opinion about it. > > I would expect that EquivID be used much more often than Ref, or both > at the same time. > > I am not so sure about the MapToID / MapFromID.. What's the purpose of > that? I think I understand how it works, but what would be an example > for a use case in which the EquivID wouldn't be good enough? > > Markus > > On 8/16/07, *Drummond Reed* <drummond.reed@cordance.net > <mailto:drummond.reed@cordance.net>> wrote: > > Markus et al: > > > > I forgot to mention on today's call that it was Markus' message > yesterday, plus the talk Les and I had, that inspired the new synonym > proposal separating synonym semantics. Specifically Markus said: > > > > > Oh and by the way, what I never liked about Refs is that to me it > seems they do two different things at the same time. They say "This > identifier is a synonym" and "Follow it to find something". I > understand those two things are very closely linked, but we STILL have > no synonym element that simply says "This identifier is a synonym" > without any additional semantics like "follow it" or "it's canonical" > or "it's local". > > > > This is exactly what the new EquivID element will do, and why it is > decoupled from Ref in this proposal. Ref only means "follow this > identifier to discover another XRD describing this resource" and > nothing more. Markus went on to say: > > > > > Personally I would have chosen only a single element with optional > attributes called <Synonym follow="true" > canonical="false">@ootao*steven</Synonym>, instead of having four or > five different elements that have so similar semantics. > > > > Where I differ with Markus over this approach is that XML schema > semantics don't allow us to specify the zero-or-one cardinality > constraint that we want to have on CanonicalID and MapToID, so even > though it is more verbose, having separate elements lets us express > this constraint cleanly. > > > > In any case, this afternoon I spent time to reflect the feedback and > fully fleshed out the new synonym proposal at: > > > > http://wiki.oasis-open.org/xri/XriCd02/SynonymSemantics > > > > I urge everyone on this thread to review it and post any and all > feedback to the list so we can include the new writeup in ED04 next week. > > > > BTW, in case you haven't read the minutes, we closed ALL OTHER ISSUES > on the telecon today, so if we have consensus on this, we are FULL > GREEN LIGHT to finish and vote on this spec by the end of the month!! > > > > =Drummond > > > > ------------------------------------------------------------------------ > > *From:* markus.sabadello@gmail.com <mailto:markus.sabadello@gmail.com> > [mailto: markus.sabadello@gmail.com > <mailto:markus.sabadello@gmail.com>] *On Behalf Of *Markus Sabadello > *Sent:* Thursday, August 16, 2007 10:58 AM > *To:* Gabe Wachob > *Cc:* Peter Davis; Drummond Reed; Les Chasen; William Barnhill; > steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>; XRI TC; > Andy Dale > *Subject:* Re: [xri] CID changes in wd11 > > > > > ... and I just ran out of quarters and dropped from the call :) > > Anyway I'm going to read through Drummond's new proposal.. What I > still understood on the call was that it includes a new element (equiv > id or something like that) that simply states identifier synonymity > without anything else, and I like that, since as I said in my other > mail the Ref element always seemed to me to do two different things at > the same time (identifier synonymity AND instructions to the resolver > to follow the Ref). > > Markus > > On 8/16/07, *Gabe Wachob* <gabe.wachob@amsoft.net > <mailto:gabe.wachob@amsoft.net>> wrote: > > And I just learned from my office-mate and from Markus' email that > Skype is > down!!! > > Ol fashion cell call then ;-) > > > -----Original Message----- > > From: Gabe Wachob [mailto: gabe.wachob@amsoft.net > <mailto:gabe.wachob@amsoft.net>] > > Sent: Thursday, August 16, 2007 10:04 AM > > To: 'Peter Davis'; 'Drummond Reed'; 'Les Chasen'; > > markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org>; 'William > Barnhill' > > Cc: steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>; 'XRI > TC'; 'Andy Dale' > > Subject: RE: [xri] CID changes in wd11 > > > > This gets back to the fundamental meta-architecture we're trying to fit > > in: > > URIs. > > > > URIs are just identifiers and what real world things you associate with > > them > > is a social issue - not a technical one. > > > > "Proving" equality can only be a *definitional* task - we can say > that two > > things are "equal" because we define them to be equal. But we can never > > "prove" that they are equal without jumping out of the architectural > plane > > of the Internet... (well, I suppose for very narrow classes of > resources, > > like cryptoblobs, maybe we could do some "proofs", but that's a > degenerate > > case). > > > > I think Bill's questions, as stimulating as they were, are leading is off > > the important issue of what do we define, through syntax or resolution > > *only*, to be equivalent. We don't really care about other equivalence > > mechanisms - those are clearly out of scope. > > > > -gabe > > > > P.S. I'm skypeing in now. > > > > > -----Original Message----- > > > From: Peter Davis [mailto:peter.davis@neustar.biz > <mailto:peter.davis@neustar.biz>] > > > Sent: Thursday, August 16, 2007 5:51 AM > > > To: Drummond Reed; Les Chasen; markus.sabadello@xdi.org > <mailto:markus.sabadello@xdi.org>; William > > Barnhill > > > Cc: steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>; XRI > TC; Andy Dale > > > Subject: Re: [xri] CID changes in wd11 > > > > > > In reality, of course, we've not proved a relationship at all.. Merely > > > hinted at a relationship between identifiers. Nothing in the XRDS > > > provides > > > a level of veracity which would support a proof. All we can really > say > > (I > > > think, unless I am missing a critical facet of this argument): > > > > > > "An anonymous party, who is authorized by a registries security > > > policy, > > > allowed a forward reference to another identifier" and similarly, > > > > > > "An anonymous party, who is authorized by a registries security > > > policy, > > > allowed a backwards reference to another identifier" > > > > > > Since we are not including the asserting parties security tokens and > > > corresponding policies into the XRDS (and I do not think that we > > should). > > > This equivalence use case can be partially solved, but I think to do > > real > > > proofs, we need much more (as yet unspecified) security material. > > > > > > I think it would be disingenuous to imply this proves anything > about the > > > relationship between two parties. > > > > > > =peterd > > > > > > > > > > > > On 8/16/2007 3:01 AM, "Drummond Reed" <drummond.reed@cordance.net > <mailto:drummond.reed@cordance.net>> > > wrote: > > > > > > > Les, regarding your first sentence below ("They are all different > > > resources > > > > with a declaration of synonimty via refs."), I think Marcus makes a > > good > > > > point when he clarified that sometimes when we use "XRI > authority" we > > > are > > > > referring to the "resource represented by an XRI" and sometimes > we are > > > > referring to "the resource descriptor (XRD) to which the XRI > > resolves". > > > This > > > > leads to a lot of confusion. The XRI glossary (in XRI Syntax 2.0) is > > > clear > > > > that an eXtensible Resource Identifier identifies a *resource* and > > that > > > the > > > > resource decriptor format to which an identifier resolves (an > > eXtensible > > > > Resource Descriptor) is a *descriptor of the resource*. So we always > > > have > > > > these three pieces involved: the identifier, the resource, and the > > > resource > > > > descriptor (which I think of as standing "between" the identifer and > > the > > > > resource). I think it would be clearer in these discussions of > > synonyms > > > if > > > > we used these terms instead of "XRI authority" due to its amibuity > > about > > > > whether you are referring to a resource or a resource descriptor. > > > > > > > > > > > > > > > > For example, if you apply these terms to your answer to Bill's > > question, > > > > "They are all different resources with a declaration of synonimty > via > > > > refs.", the answer doesn't make sense. Resources can never be > > > synonymous, > > > > only identifiers of resources can be synonymous. > > > > > > > > > > > > > > > > So, returning to Bill's questions: > > > > > > > > > > > > > > > > Fred: "@ootao*steven and =steven.churchill identify the same > > > > resource" > > > > Alice: "Prove it" > > > > Fred: ??? > > > > > > > > Fred: "@ootao*steven and =steven.churchill identify > different > > > > resources" > > > > Alice: "Prove it" > > > > Fred: ??? > > > > > > > > > > > > > > > > In essence, Bill's first question is asking, "Can you prove that two > > > > different identifiers from different identifier authorities identify > > the > > > > same resource?", and his second is asking, "Can you prove the same > > thing > > > in > > > > the negative?" > > > > > > > > > > > > > > > > With the CanonicalID-can-be-polyarchical proposal in ED03, the answer > > is > > > > clearly "Yes" to the first question, and "No" to the second (in > fact I > > > don't > > > > think we've ever had an answer to Bill's second question, because a > > lack > > > of > > > > synonyms does not necessary mean that two identifiers don't identify > > the > > > > same resource.) With the CanonicalID-must-be-hierachical > proposal, the > > > > answer to the first question is clearly "Not with a CanonicalID". As > > you > > > > point out, if we go the CanonicalID-must-be-hierachical approach, > the > > > > question of whether XRI resolution infrastructure should be able to > > > answer > > > > Bill's first question is one we need to decide as a TC is either in- > > > scope or > > > > out-of-scope. > > > > > > > > > > > > > > > > We'll take up on tomorrow's call. Talk to you then, > > > > > > > > > > > > > > > > =Drummond > > > > > > > > > > > > > > > > > > > > > > > > _____ > > > > > > > > From: Chasen, Les [mailto:les.chasen@neustar.biz > <mailto:les.chasen@neustar.biz>] > > > > Sent: Wednesday, August 15, 2007 2:59 PM > > > > To: markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org>; > barnhill_william@bah.com <mailto:barnhill_william@bah.com> > > > > Cc: drummond.reed@cordance.net > <mailto:drummond.reed@cordance.net>; steven.churchill@xdi.org > <mailto:steven.churchill@xdi.org>; > > > > xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>; > andy.dale@ootao.com <mailto:andy.dale@ootao.com> > > > > Subject: Re: [xri] CID changes in wd11 > > > > > > > > > > > > > > > > They are all different resources with a declaration of synonimty via > > > refs. > > > > I think it is open for debate whether we need to prove it. > > > > > > > > In the real world it is not necessarily proved when a claim such as > > this > > > is > > > > made. The trust in the claim will depend on the context in which the > > > claim > > > > is being made. Under some circumstances you can obviously see a need > > to > > > > prove the relationship in many other you can see not needing proof. > > It > > > is a > > > > question of level of risk. Similarily, I think this is the > > > responsibility of > > > > the client application/service as they are the only ones that can > > decide > > > the > > > > proper level of authentication/approval of various claims. I can see > > > myself > > > > writing applications that choose to ignore synonyms because my > risk is > > > high > > > > and my trust levels are low. > > > > > > > > > > > > -------------------------- > > > > http://xri.net/=les.chasen <http://xri.net/=les.chasen> > > > > > > > > > > > > ----- Original Message ----- > > > > From: markus.sabadello@gmail.com > <mailto:markus.sabadello@gmail.com> < markus.sabadello@gmail.com > <mailto:markus.sabadello@gmail.com>> > > > > To: Barnhill, William <barnhill_william@bah.com > <mailto:barnhill_william@bah.com>> > > > > Cc: Drummond Reed < drummond.reed@cordance.net > <mailto:drummond.reed@cordance.net>>; Steven Churchill > > > > <steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>>; > Chasen, Les; xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org> > > > > <xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>>; > Andy Dale <andy.dale@ootao.com <mailto:andy.dale@ootao.com>> > > > > Sent: Wed Aug 15 17:42:26 2007 > > > > Subject: Re: [xri] CID changes in wd11 > > > > > > > > I think it would go about like this (no guarantees!!): > > > > > > > > For question 1: > > > > > > > > if (Fred == Drummond) { > > > > > > > > Fred: "Just resolve them and look at their XRDs. They have the same > > > > CanonicalID, therefore they identify the same resource. They have > > > different > > > > GlobalIDs. At least one of them has either a Ref or BackRef". > > > > > > > > } else if (Fred == Steven || Fred == Les) { > > > > > > > > Fred: "Just resolve them. They have different CanonicalIDs. But > one > > of > > > > them has a Ref, therefore they identify the same resource." > > > > > > > > } > > > > > > > > > > > > For question 2: > > > > > > > > if (Fred == Drummond || Fred == Les || Fred == Steven) { > > > > > > > > Fred: "Just resolve them. If there is no synonym element in either > > > XRD, > > > > they are different resources." > > > > > > > > } > > > > > > > > Markus > > > > > > > > > > > > On 8/15/07, Barnhill, William <barnhill_william@bah.com > <mailto:barnhill_william@bah.com>> wrote: > > > > > > > > Quick question if I can, supposing the following > conversations > > > what > > > > are > > > > Fred's responses? > > > > > > > > Fred: "@ootao*steven and =steven.churchill identify the same > > > > resource" > > > > Alice: "Prove it" > > > > Fred: ??? > > > > > > > > Fred: "@ootao*steven and =steven.churchill identify different > > > > resources" > > > > Alice: "Prove it" > > > > Fred: ??? > > > > > > > > This would help me greatly, though may be a rehashing for > many > > > of > > > > you, > > > > Bill > > > > > > > > -- > > > > William Barnhill Phone: (315) 491-6765 > > > > Associate Email: > > > barnhill_william@bah.com <mailto:barnhill_william@bah.com> > > > > <mailto:barnhill_william@bah.com <mailto:barnhill_william@bah.com>> > > > > Booz | Allen | Hamilton i-name: = Bill.Barnhill > > > > "Delivering results that endure" > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: markus.sabadello@gmail.com > <mailto:markus.sabadello@gmail.com> > > > <mailto:markus.sabadello@gmail.com <mailto:markus.sabadello@gmail.com>> > > > > [mailto: markus.sabadello@gmail.com > <mailto:markus.sabadello@gmail.com> > > <mailto:markus.sabadello@gmail.com <mailto:markus.sabadello@gmail.com>> > > > ] On > > > > Behalf Of Markus Sabadello > > > > Sent: Wednesday, August 15, 2007 3:57 PM > > > > To: Drummond Reed > > > > Cc: Steven Churchill; Chasen, Les; > xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org> > > > > <mailto: xri@lists.oasis-open.org > <mailto:xri@lists.oasis-open.org>> ; Andy Dale > > > > Subject: Re: [xri] CID changes in wd11 > > > > > > > > > > > > I read all this 3 times now.. I can't shake the feeling that > > > > everyone is > > > > saying almost the same thing and that the problem lies in > > > > terminology such > > > > as "XRD", "authority" and "resource". > > > > > > > > Here are a few simple statements: > > > > 1. "@ootao*steven and =steven.churchill identify the same > > > resource". > > > > 2. "@ootao*steven and = steven.churchill are different XRI > > > > authorities". > > > > 3. "The CanonicalID is the preferred and unique identifier > > > (primary > > > > key) of > > > > a real-world resource." > > > > 4. "The CanonicalID is the preferred and unique identifier > > > (primary > > > > key) of > > > > an XRI authority." > > > > > > > > I think we all agree on (1). Those are two i-names > registered > > by > > > and > > > > identifying our friend Steven Churchill (the resource). > > > > > > > > I think we also all agree on (2), although I am not > completely > > > sure > > > > about > > > > that. Let me know if you disagree here. My understanding is > > that > > > > every XRI > > > > (except LOCAL synonyms) has an "authority" of its own. Local > > > > synonyms share > > > > the same authority, but "polyarchical" synonyms have > different > > > > authorities. > > > > Independent of that, when you resolve an XRI, you could of > > > course > > > > get > > > > different authorities (due to ref processing). > Technically (in > > > the > > > > GRS and > > > > the OpenXRI server), there is a 1:1 relationship between an > > > > authority and an > > > > XRD. > > > > > > > > Regarding (3) and (4), I think this is where the differences > > > lie. > > > > > > > > If you support (3), which I suspect Drummond does, then you > > > would > > > > use the > > > > same CanonicalID for all your i-names. I got ONE i-number > > which > > > > identifies > > > > ME, and I am supposed to use it as a CanonicalID for all i- > > names > > > I > > > > have > > > > (=markus, @id*markus, =peacekeeper, etc.). Those would all > > have > > > the > > > > same > > > > CanonicalID. I am able to establish a notion of > synonymity of > > > > identifiers > > > > BEFORE I do service endpoint selection! > > > > > > > > If you like (4) better (Les? Steven?), then the CanonicalID > > > > identifies an > > > > XRI authority instead of a real-world resource. I just > > resolved > > > > @ootao*steven and =steven.churchill , and they have different > > > > CanonicalIDs. > > > > But there is a Ref, which tells me they are synonyms. Like in > > > (3) I > > > > also > > > > have a notion of synonymity of identifiers before I do > service > > > > endpoint > > > > selection, but the CanonicalIDs of the identifiers are > > > different. > > > > Which is > > > > not a problem, since during resolution with ref processing > > > (OpenID > > > > for > > > > example), I get the same CanonicalID for both identifiers. > > > > > > > > ----> I think all this comes down to what's the relationship > > > between > > > > the > > > > terms "real-world resource" and "XRI authority", and which of > > > them > > > > should be > > > > identified by the CanonicalID. > > > > > > > > I have a question for Les (I'm not trying to make a point > with > > > that > > > > question, I really want to know): What happens when my i-name > > > > =markus > > > > expires (because I forget to pay for it) and then my evil > > > neighbour > > > > registers it? Will it get a new i-number? I hope so!!! > > Otherwise > > > he > > > > will be > > > > able to access all the OpenID relying parties I ever used, > > > right? > > > > Therefore, > > > > "The CanonicalID of the authority =markus changed", no? > Which > > is > > > a > > > > good > > > > thing, since it now refers to a different resource (my > > > neighbour), > > > > no? Or > > > > would you express this in different words? > > > > > > > > Oh and by the way, what I never liked about Refs is that > to me > > > it > > > > seems they > > > > do two different things at the same time. They say "This > > > identifier > > > > is a > > > > synonym" and "Follow it to find something". I understand > those > > > two > > > > things > > > > are very closely linked, but we STILL have no synonym > element > > > that > > > > simply > > > > says "This identifier is a synonym" without any additional > > > semantics > > > > like > > > > "follow it" or "it's canonical" or "it's local". > Personally I > > > would > > > > have > > > > chosen only a single element with optional attributes called > > > > <Synonym > > > > follow="true" canonical="false">@ootao*steven</Synonym>, > > instead > > > of > > > > having > > > > four or five different elements that have so similar > > semantics. > > > > > > > > I don't know if any of this helps or makes things even more > > > > complicated, > > > > after all I'm still new to this as compared to you XRI > > dinosaurs > > > :) > > > > Just > > > > trying to sum up my impressions of this ongoing discussion.. > > > > > > > > greetings, > > > > Markus > > > > > > > > > > > > > > > > > > > > On 8/14/07, Drummond Reed < drummond.reed@cordance.net > <mailto:drummond.reed@cordance.net>> wrote: > > > > > > > > What I am hearing from Steve and Les essentially > boils > > > down > > > > to this: > > > > a CanonicalID value should not be allowed to be > polyarchical, > > > > because if it > > > > is polyarchical, it might need to change. If a CanonicalID > > value > > > > MUST be > > > > hierachical (which in had to be in order to be verified in > > WD11 > > > ED02 > > > > -- the > > > > draft I believe Les is proposing we revert CanonicalID to), > > then > > > > indeed > > > > verification is indeed simpler, as a CanonicalID MUST be > > issued > > > by > > > > the same > > > > authority authoritative for the XRD in which it appears. And > > if > > > an > > > > authority > > > > uses a persistent hierachical identifier as a > CanonicalID, it > > > never > > > > needs to > > > > change, because a hierachical identifier is always under the > > > control > > > > of the > > > > authority that issues it, whereas a polyarchical > identifier is > > > not. > > > > > > > > > > > > > > > > Lastly it follows that if a CanonicalID value MUST be > > > > hierarchical > > > > (which was the proposed definition of the GlobalID element), > > > then > > > > the > > > > primary rationale for GlobalID goes away (there may still > > > another > > > > secondary > > > > rationale for it, but that's another subject). > > > > > > > > > > > > > > > > However if we go this direction, it leaves us with a > > > > different > > > > problem: how can a real-world resource (such as a person) > > prove > > > that > > > > they > > > > are the same resource represented by two different XRDs with > > two > > > > different > > > > CanonicalIDs issued by two different parent authorities? > > > > > > > > > > > > > > > > We'd need to move the burden of this proof to our > > > > polyarchical > > > > synonyms, i.e., Refs and Backrefs. In this approach, XRD #1 > > from > > > > parent > > > > authority #1 could assert that it represented the same > > resource > > > as > > > > XRD #2 > > > > from parent authority #2 by including a Ref element whose > > value > > > was > > > > an > > > > identifier that resolved to XRD #2 (preferably the > CanonicalID > > > for > > > > XRD #2, > > > > but any absolute identifier for XRD #2 would work). > > > > > > > > > > > > > > > > To verify that this synonym assertion was true, > an XRI > > > > resolver > > > > would need to do the same thing proposed in ED03 section > 12.2, > > > i.e., > > > > confirm > > > > that a corresponding Backref element exists in XRD #2 > pointing > > > back > > > > to an > > > > identifier for XRD #2 (again, preferably the CanonicalID for > > XRD > > > > #1). I > > > > would argue that we should also allow a Ref element to be > used > > > for > > > > verification, i.e., if XRD #1 contains a Ref element > pointing > > to > > > XRD > > > > #2, and > > > > XRD #2 contains a Ref element pointing back to XRD #1, the > > > synonyms > > > > are > > > > verified in *both* directions. > > > > > > > > > > > > > > > > Since this "Ref verification" only works > > polyarchically > > > on > > > > Ref > > > > elements, it is a separate process that "CanonicalID > > > verification" > > > > which > > > > only works hierarchically on CanonicalID elements. This means > > > we'd > > > > need to > > > > add another XRI resolution parameter for requesting Ref > > > verification > > > > (I'd > > > > propose to call it "ref" but we already have the "refs" > > > parameter > > > > which is > > > > used to control whether refs are followed in service > endpoint > > > > selection, so > > > > another name would be better). > > > > > > > > > > > > > > > > The key thing we lose by going this direction is the > > > ability > > > > for the > > > > resource represented by an XRD to assert a polyarchical > > > identifier > > > > as its > > > > canonical identifier. Let me give an example. > > > > > > > > > > > > > > > > If I want to go into twelve different businesses > today > > > to > > > > establish > > > > an account and I want to prove to each of them that I > have the > > > same > > > > identity > > > > (for example, so they all give me good credit), I can > show all > > > > twelve of > > > > them the same credential with the same identifier (say > it's my > > > WA > > > > state > > > > driver's license #). If they believe this credential (which > > they > > > can > > > > verify), they can record this identifier in their databases > > and > > > they > > > > don't > > > > need to assign me their own local identifier (they may still > > > want to > > > > do > > > > that, but they don't HAVE to do that). This is the > > > > CanonicalID-can-be-polyarchical model proposed in ED03. > > > > > > > > > > > > > > > > By contrast, if none of the twelve businesses will > > > accept my > > > > my WA > > > > state driver's license # (or another external identifier) as > > > their > > > > identifier for me, they all MUST assign me their own local > > > > identifiers. To > > > > prove I am the same person, they can all put in their records > > > that I > > > > have a > > > > WA state driver's license #, but to do this they MUST > store at > > > least > > > > two > > > > identifiers: the one they assigned me, and my WA state > > driver's > > > > license #. > > > > This is the CanonicalID-must-be-hierarchical model that I > > > believe > > > > Les and > > > > Steve are proposing. > > > > > > > > > > > > > > > > Either model will work. They have contrasting > > > > advantages/disadvantages: > > > > > > > > > > > > > > > > CANONICALID-CAN-BE-POLYARCHICAL > > > > > > > > Advantages: > > > > > > > > - XRI authority can assert the same identifier > > > everywhere if > > > > it > > > > wants > > > > > > > > - Separate Ref verification process is not needed to > > > prove > > > > cross-domain identity > > > > > > > > - Consuming applications do not need to store more > > than > > > one > > > > identifier to support cross-domain identification > > > > > > > > Disadvantages: > > > > > > > > - CanonicalID can change > > > > > > > > - Verification of polyarchical CanonicalID value > > > involves an > > > > extra > > > > resolution step > > > > > > > > - GlobalID is needed for verification of polyarchical > > > > CanonicalIDs > > > > > > > > > > > > > > > > CANONICALID-MUST-BE-HIERACHICAL > > > > > > > > Advantages: > > > > > > > > - CanonicalID never needs to change > > > > > > > > - Verification of polyarchical CanonicalID values is > > > more > > > > efficient > > > > > > > > - GlobalID is not needed for verification > > > > > > > > Disadvantages: > > > > > > > > - XRI authority cannot assert the same identifier > > > everywhere > > > > if it > > > > wants > > > > > > > > - Separate Ref verification process is needed to > prove > > > > cross-domain > > > > identity > > > > > > > > - Consuming applications need to store more than one > > > > identifier to > > > > support cross-domain identification > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > =Drummond > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Steven Churchill > > > > [mailto:steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>] > > > > Sent: Tuesday, August 14, 2007 10:46 AM > > > > To: 'Chasen, Les'; 'Drummond Reed'; xri@lists.oasis- > > > open.org <http://open.org> > > > > Cc: 'Andy Dale' > > > > > > > > Subject: RE: [xri] CID changes in wd11 > > > > > > > > > > > > > > > > > > > > > > > > Les is taking the correct position in this debate. > > > > > > > > > > > > > > > > XRI Resolution has long supported an important > > identity > > > > model where > > > > an XRI authority's identity can be distinguished by its > > > CanonicalID. > > > > For > > > > example, if resolving an XRI produces a (verifiable) > > > CanonicalID, > > > > then, as > > > > an XRI resolution client, I can treat that XRI as a > synonym to > > a > > > > unique XRI > > > > authority-a unique record in the global database that Les > > > describes > > > > below. I > > > > like to think of this database as a hierarchical graph, but > > > these > > > > are really > > > > two legitimate ways of talking about the same identity model. > > > Each > > > > record in > > > > Les' database is just a node in my graph. In both cases, > these > > > > records/nodes > > > > can be thought of as "XRI authorities", and in both cases the > > > > absolute > > > > identity of this XRI authority-that characteristic which > > > > distinguishes it > > > > from all other XRI authorities-is its CanonicalID. > > > > > > > > > > > > > > > > Given this basic identity model, any resolution that > > > > produces a > > > > different verifiable CanonicalID simply addresses a different > > > > authority. > > > > This is by definition of the model. (It is the same way that > > in > > > a > > > > relational > > > > model, a different PK must address a different record.) Say I > > > > resolve a > > > > given XRI with a given set of input parameters and it > produces > > a > > > > verifiable > > > > CID. Now say I resolve it a minute later with the same set of > > > input > > > > parameters and it produces another verifiable CID. This > > scenario > > > can > > > > and > > > > does occur-especially in the face of Ref processing and > people > > > > provisioning > > > > their SEPs. For example, I can (right now) simply add an SEP > > to > > > > @ootao*steve's authority, and then the same resolution call a > > > minute > > > > later > > > > will return a different verifiable CID. So, indeed, a client > > can > > > get > > > > back a > > > > different XRI authority when making two consecutive > > (equivalent) > > > > resolution > > > > calls. But this is all fine and good because it is the way > > that > > > we > > > > designed > > > > Ref processing (a long, long time ago.) Given this behavior, > > the > > > > (CanonicalID) identity model is still sound, because, by > > > definition, > > > > the > > > > second resolution call simply returns a different XRI > > authority. > > > > > > > > > > > > > > > > As for the CanonicalID being optional, <CanonicalID> > > is > > > > simply an > > > > element in the XML metadata that one XRI authority uses to > > > describe > > > > another. > > > > The first authority can choose to use it or not. If it does > > not > > > use > > > > it, then > > > > a Resolution client obviously cannot use the element to > > > distinguish > > > > authorities. No harm no foul. As for immutability: if > > resolving > > > two > > > > XRIs > > > > produce to different verifiable CanonicalIDs then, by > > definition > > > of > > > > the > > > > model, they address different authorities-two different > > records > > > in > > > > Les' > > > > global database. > > > > > > > > > > > > > > > > I really respect and appreciate Les' effort to > protect > > > these > > > > fundamentals. The introduction of GlobalID is a giant step in > > > the > > > > wrong > > > > direction. It is an attempt to define a more complicated > > > identity > > > > model in > > > > the interest of solving a newly introduced use case. If that > > use > > > > case is > > > > indeed important (which I doubt) then it should be solved > > within > > > the > > > > existing model-not by trying to define a new one. > > > > > > > > > > > > > > > > ~ Steve > > > > > > > > > > > > > > > > > > > > > > > > PS: For the typical disclaimer, I need to point out > > that > > > XRI > > > > resolution supports many identity models, and resolution > > clients > > > may > > > > not > > > > care at all about using a CanonicalID in the fashion > described > > > > above. > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Chasen, Les [mailto: > > > les.chasen@neustar.biz <mailto:les.chasen@neustar.biz> > > > > <mailto:les.chasen@neustar.biz <mailto:les.chasen@neustar.biz>> ] > > > > Sent: Tuesday, August 14, 2007 12:16 AM > > > > To: Drummond Reed; xri@lists.oasis-open.org > <mailto:xri@lists.oasis-open.org> > > > > <mailto:xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>> > > > > Subject: RE: [xri] CID changes in wd11 > > > > > > > > > > > > > > > > Hi Drummond, > > > > > > > > > > > > > > > > Welcome back hope you had a nice vacation. > > > > > > > > > > > > > > > > Yes CID has always been optional and we cannot do > > > anymore > > > > than > > > > recommend that it be persistent. We have also never > actually > > > > spelled out > > > > that it cannot change. However, the implication has always > > been > > > > there that > > > > it is immutable. That is until the introduction of globalId > > and > > > the > > > > specification, for the first time, stating that CID is > > editable. > > > I > > > > think > > > > this is a huge architectural mistake given where we are > in the > > > life > > > > of XRI. > > > > We have a base of applications out there, at our insistence, > > > using > > > > CID as a > > > > persistent key. It is too late to change that now. > > > > > > > > > > > > > > > > I therefore propose that we take CID back to where it > > > was in > > > > WD10 > > > > and add extra text to codify that it should be left > immutable. > > > > Personally I > > > > would make it a MUST requirement but I recognize for the same > > > reason > > > > that it > > > > is an optional field and persistence is a recommendation we > > > cannot > > > > really > > > > require that it MUST be immutable. So a SHOULD be immutable > > is > > > > fine. > > > > > > > > > > > > > > > > contact: =les < http://xri.net/=les > > > <http://xri.net/=les> > > > > > > > > > voice : =les/(+phone) > > <http://xri.net/=les/%28+phone%29> > > > > > > > > chat: =les/skype/chat < > http://xri.net/=les/skype/chat <http://xri.net/=les/skype/chat> > > > > <http://xri.net/=les/skype/chat> > > > > > > > > > pibb me =les/+pibb < http://xri.net/=les/+pibb> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Drummond Reed > > > > [mailto:drummond.reed@cordance.net > <mailto:drummond.reed@cordance.net>] > > > > Sent: Tuesday, August 14, 2007 1:37 AM > > > > To: Chasen, Les; xri@lists.oasis-open.org > <mailto:xri@lists.oasis-open.org> > > > > <mailto:xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org> > > > > > Subject: RE: [xri] CID changes in wd11 > > > > > > > > > > > > > > > > Les, > > > > > > > > > > > > > > > > I have just returned from vacation and am still > > catching > > > up > > > > on email > > > > and the minutes of the meetings while I was gone. But > > regarding > > > your > > > > point > > > > about CIDs, here's some initial thoughts: > > > > > > > > > > > > > > > > 1) First, CanonicalID, like all synonym elements, > has > > > always > > > > been > > > > optional. There's no requirement than an XRD MUST assert an > > > > CanonicalID. > > > > It's RECOMMENDED, but for obvious reasons it's not > REQUIRED at > > > the > > > > spec > > > > level because some users of XRDS architecture don't need > > > > CanonicalIDs at > > > > all. > > > > > > > > > > > > > > > > 2) Second, there is no requirement that a CanonicalID > > > value > > > > be > > > > persistent. Again, it's RECOMMENDED, but not REQUIRED, as > some > > > > authorities > > > > don't either want or need persistent identifiers. > > > > > > > > > > > > > > > > So my first point is that as much as it would be > nice > > > for > > > > all XRDs > > > > to: a) have a CanonicalID value, and b) make it a persistent > > > > identifier that > > > > never changes, we have never (in WD10 or any earlier draft) > > > required > > > > for > > > > either to be true. An authority has always been able to > assert > > > any > > > > CanonicalID value they want, and change it anytime they > want. > > > The > > > > only > > > > change from WD10 to WD11 is that the cardinality of > > CanonicalID > > > went > > > > from > > > > zero-or-more to zero-or-one. > > > > > > > > > > > > > > > > Secondly, the main purpose of XRI synonym > architecture > > > is to > > > > model > > > > the real world in which a resource may have any number of > > > > identifiers > > > > assigned to it by any number of authorities. Each of these > > > > identifiers may > > > > be either reassignable or persistent. WD11 is the first > draft > > in > > > > which we > > > > have, in section 11 and specifically in Table 23 (page 60 of > > the > > > > PDF), fully > > > > captured the semantics necessary for an authority to assert > > the > > > set > > > > of > > > > identifiers it uses to identify a resource in such a manner > > that > > > > client > > > > applications have all the metadata they need to > understand how > > > to > > > > consume > > > > those identifiers to maintain a reference to the resource. > > > > > > > > > > > > > > > > Your specific concern is that client applications be > > > able to > > > > know > > > > which identifier they can use as a persistent global foreign > > key > > > for > > > > a > > > > resource. Table 23 explains that of the five synonym > elements > > > > available, > > > > only three fit the requirements of a global foreign key: > > > > CanonicalID, > > > > GlobalID, and Ref. LocalID and Backref do not meet the > > > requirements > > > > because: > > > > > > > > > > > > > > > > * LocalID is relative and not absolute. > > > > > > > > * Backref is an assertion that another authority is > > > > referencing the > > > > synonyms in the current XRD to identify the resource. > > > > > > > > > > > > > > > > However the other three - CanonicalID, GlobalID, and > > Ref > > > -- > > > > *all* > > > > can meet the requirements of global foreign keys for a > > resource. > > > > This begs > > > > the question: why have three XRD synonym elements that > can all > > > serve > > > > as > > > > global foreign keys? > > > > > > > > > > > > > > > > Table 23 provides the answer. GlobalID and Ref > cleanly > > > > separate > > > > global keys for a resource into two categories for trust > > > purposes: > > > > > > > > > > > > > > > > 1) Category #1 - GlobalIDs - are hierachical > > identifiers > > > > that are > > > > assigned by the authority for the XRD and thus can be > verified > > > > hierachically. > > > > > > > > > > > > > > > > 2) Category #2 - Refs - are polyarchical identifiers > > > that > > > > are > > > > assigned by authorities OTHER than the authority for the XRD > > and > > > > which thus > > > > must be verified polyarchically, i.e., by confirming the > > > > corresponding > > > > Backref. > > > > > > > > > > > > > > > > Given that between these two categories, we've > covered > > > 100% > > > > of the > > > > use cases (to the best of my knowledge), what then is the > > > purpose of > > > > the > > > > CanonicalID element? Why do we even need it? > > > > > > > > > > > > > > > > The answer is that, because an authority can assert > > any > > > > number of > > > > GlobalIDs or Refs for a resource (the use cases for asserting > > > > multiple > > > > GlobalIDs are pretty weak but the use cases for asserting > > > multiple > > > > Refs can > > > > be very strong), the additional value of the CanonicalID > > element > > > is > > > > that it > > > > gives XRD authorities a way to assert which ONE of these > > > multiple > > > > global > > > > foreign keys the authority RECOMMENDS client applications use > > to > > > > maintain a > > > > reference to the resource. > > > > > > > > > > > > > > > > So the net net is that the value(s) of the GlobalID > > > > (zero-or-more), > > > > Ref (zero-or-more), and the CanonicalID (zero-or-one) > elements > > > are > > > > all > > > > absolute identifiers that can serve as global foreign > keys for > > a > > > > resource. > > > > All the element tag tells you about these identifiers is: > > > > > > > > > > > > > > > > * Was it assigned by the authority for the XRD > > > (GlobalID)? > > > > > > > > * Was it NOT assigned by the authority for the XRD > > > (Ref)? > > > > > > > > * Of all the options, is it the recommended global > > > foreign > > > > key for > > > > the resource (CanonicalID)? > > > > > > > > > > > > > > > > This reveals the precise reason that the value of a > > > > CanonicalID > > > > element in an XRD could change over time: the parent > authority > > > > learns that > > > > the recommended global foreign key for a resource is > different > > > than > > > > the one > > > > the parent authority has heretofore been recommending. For > > > example, > > > > a parent > > > > authority could initially publish: > > > > > > > > > > > > > > > > <XRDS> > > > > > > > > <XRD> > > > > > > > > <Query>*example</Query> > > > > > > > > <GlobalID>=!1</GlobalID> > > > > > > > > > > > > <Ref>http://example.com/example/resource#1234</Ref> > > > > > > > > > > > > <Ref> https://example.com/example/resource#1234 > > > > <https://example.com/example/resource#1234 > <https://example.com/example/resource#1234>> </Ref> > > > > > > > > > > > > > > > <CanonicalID>https://example.com/example/resource#1234</CanonicalID> > > > > > > > > </XRD> > > > > > > > > </XRDS> > > > > > > > > > > > > > > > > But the resource identified by these three synonyms > > may > > > lose > > > > control > > > > over the domain name " example.com <http://example.com> < > http://example.com> ". In > > > this > > > > case, even though > > > > https://example.com/example/resource#1234 > > > > < https://example.com/example/resource#1234> is a persistent > > identifier > > > (see > > > > below), the authority may decide that at that point it is > > better > > > to > > > > recommend a different persistent identifier as the > > CanonicalID. > > > Thus > > > > the XRD > > > > could change to: > > > > > > > > > > > > > > > > <XRDS> > > > > > > > > <XRD> > > > > > > > > <Query>*example</Query> > > > > > > > > <GlobalID>=!1</GlobalID> > > > > > > > > > > > > <Ref> http://example.com/example/resource#1234</Ref> > > > > > > > > > > > > <Ref> https://example.com/example/resource#1234 > <https://example.com/example/resource#1234> > > > > <https://example.com/example/resource#1234> </Ref> > > > > > > > > > <CanonicalID>=!1</CanonicalID> > > > > > > > > </XRD> > > > > > > > > </XRDS> > > > > > > > > > > > > > > > > Note that the identifier " > > > > https://example.com/example/resource#1234" > > > > did NOT go away as a persistent global foreign key for the > > > resource. > > > > It's > > > > still there as a Ref, just as it was in the first > example. The > > > only > > > > change > > > > is that the CanonicalID now points to a different global > > foreign > > > key > > > > as the > > > > preferred one. > > > > > > > > > > > > > > > > Again note that NONE of the XRI synonym elements has > > the > > > > semantics > > > > that the identifier value MUST be persistent (not in WD11, > > WD10, > > > or > > > > any > > > > earlier draft). The way for a consuming application to tell > > > whether > > > > the > > > > identifier is asserted as persistent is to check for either > > XRI > > > > persistence > > > > semantics (! syntax for i-numbers) or URI persistence > > semantics > > > > (urn: or > > > > other persistent URI schemes). > > > > > > > > > > > > > > > > *********** > > > > > > > > I hope this helps. Clearly this issue is deep enough > > > that it > > > > can > > > > benefit more from direct phone or f2f discussion than from > > > email. I > > > > nominate > > > > it for the agenda for this week's TC call, but in the > meantime > > > feel > > > > free to > > > > call me if you want to discuss further. > > > > > > > > > > > > > > > > =Drummond > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Chasen, Les > > > [mailto:les.chasen@neustar.biz <mailto:les.chasen@neustar.biz>] > > > > Sent: Monday, August 13, 2007 3:16 PM > > > > To: xri@lists.oasis-open.org > <mailto:xri@lists.oasis-open.org> > > > > <mailto:xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>> > > > > Subject: [xri] CID changes in wd11 > > > > > > > > > > > > > > > > Hi all - > > > > > > > > > > > > > > > > After reviewing the latest wd11 I have one major > > > concern. > > > > This > > > > version allows a CID to be changed after it is already set. > > I > > > > believe that > > > > this is a big mistake. The CID is the persistent identifier > > for > > > the > > > > queried > > > > XRD. We need to ensure that once an XRD has a CID that that > > CID > > > > identifies > > > > that XRD forever. > > > > > > > > > > > > > > > > I have always thought of the CID as a primary key to > > the > > > > global > > > > database we have created with XRI resolution. Client > > > applications > > > > have been > > > > and are being written that depend on the value of this > primary > > > key > > > > for the > > > > mapping of an identity described by an XRDS to their > internal > > > > account > > > > structure. If we allow this primary key to be changed we > have > > > > caused a > > > > major data integrity problem. > > > > > > > > > > > > > > > > I propose that the definition of CID not only revert > > > back to > > > > the > > > > WD10 definition but we also more strongly codify that a CID > > once > > > set > > > > should > > > > never be changed. > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > contact: =les < http://xri.net/=les > > > <http://xri.net/=les> > > > > > > > > > voice : =les/(+phone) < > > > http://xri.net/=les/%28+phone%29> > > > > > > > > chat: =les/skype/chat < > http://xri.net/=les/skype/chat <http://xri.net/=les/skype/chat> > > > > <http://xri.net/=les/skype/chat> > > > > > > > > > pibb me =les/+pibb < http://xri.net/=les/+pibb> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =peterd ( http://xri.net/=peterd ) > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]