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


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xri] CID changes in wd11

Title: Re: [xri] CID changes in wd11

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,





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.


----- 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."



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,
        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
        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..
        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
                - XRI authority can assert the same identifier everywhere if it
                - 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
                - CanonicalID can change
                - Verification of polyarchical CanonicalID value involves an extra
        resolution step
                - GlobalID is needed for verification of polyarchical CanonicalIDs
                - CanonicalID never needs to change
                - Verification of polyarchical CanonicalID values is more efficient
                - GlobalID is not needed for verification
                - XRI authority cannot assert the same identifier everywhere if it
                - Separate Ref verification process is needed to prove cross-domain
                - Consuming applications need to store more than one identifier to
        support cross-domain identification
                        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
                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
                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
                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
                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:
        <Ref> https://example.com/example/resource#1234 <https://example.com/example/resource#1234> </Ref>
                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:
        <Ref> https://example.com/example/resource#1234 <https://example.com/example/resource#1234> </Ref>
                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.
                        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.
                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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]