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


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]