[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] CID changes in wd11
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]
> Sent: Thursday, August 16, 2007 10:04 AM
> To: 'Peter Davis'; 'Drummond Reed'; 'Les Chasen';
> markus.sabadello@xdi.org; 'William Barnhill'
> Cc: 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]
> > Sent: Thursday, August 16, 2007 5:51 AM
> > To: Drummond Reed; Les Chasen; markus.sabadello@xdi.org; William
> Barnhill
> > Cc: 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>
> 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]