[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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> 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] > Sent: Wednesday, August 15, 2007 2:59 PM > To: markus.sabadello@xdi.org; barnhill_william@bah.com > Cc: drummond.reed@cordance.net; steven.churchill@xdi.org; > xri@lists.oasis-open.org; 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 > > > ----- Original Message ----- > From: markus.sabadello@gmail.com <markus.sabadello@gmail.com> > To: Barnhill, William <barnhill_william@bah.com> > Cc: Drummond Reed <drummond.reed@cordance.net>; Steven Churchill > <steven.churchill@xdi.org>; Chasen, Les; xri@lists.oasis-open.org > <xri@lists.oasis-open.org>; Andy Dale <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> 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> > 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> ] 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> ; 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> 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] > Sent: Tuesday, August 14, 2007 10:46 AM > To: 'Chasen, Les'; 'Drummond Reed'; xri@lists.oasis-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> ] > Sent: Tuesday, August 14, 2007 12:16 AM > To: Drummond Reed; 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> > > > pibb me =les/+pibb <http://xri.net/=les/+pibb> > > > > > > > > > > ________________________________ > > From: Drummond Reed > [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> > 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> </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> ". 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> </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] > Sent: Monday, August 13, 2007 3:16 PM > To: 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> > > > 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]