Markus et al:
I forgot to mention on today’s call
that it was Markus’ message yesterday, plus the talk Les and I had, that
inspired the new synonym proposal separating synonym semantics. Specifically
Markus said:
> Oh and by the way, what I never liked about Refs is that to me it
seems they do two different things at the same time. They say "This
identifier is a synonym" and "Follow it to find something". I
understand those two things are very closely linked, but we STILL have no
synonym element that simply says "This identifier is a synonym"
without any additional semantics like "follow it" or "it's
canonical" or "it's local".
This is exactly what the new EquivID element
will do, and why it is decoupled from Ref in this proposal. Ref only means “follow
this identifier to discover another XRD describing this resource” and
nothing more. Markus went on to say:
> Personally I would have chosen only a single element with optional
attributes called <Synonym follow="true"
canonical="false">@ootao*steven</Synonym>, instead of having
four or five different elements that have so similar semantics.
Where I differ with Markus over this
approach is that XML schema semantics don’t allow us to specify the
zero-or-one cardinality constraint that we want to have on CanonicalID and MapToID,
so even though it is more verbose, having separate elements lets us express
this constraint cleanly.
In any case, this afternoon I spent time
to reflect the feedback and fully fleshed out the new synonym proposal at:
http://wiki.oasis-open.org/xri/XriCd02/SynonymSemantics
I urge everyone on this thread to review
it and post any and all feedback to the list so we can include the new writeup
in ED04 next week.
BTW, in case you haven’t read the
minutes, we closed ALL OTHER ISSUES on the telecon today, so if we have consensus
on this, we are FULL GREEN LIGHT to finish and vote on this spec by the end of
the month!!
=Drummond
From:
markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Thursday, August 16, 2007
10:58 AM
To: Gabe Wachob
Cc: Peter Davis; Drummond Reed;
Les Chasen; William Barnhill; steven.churchill@xdi.org; XRI TC; Andy Dale
Subject: Re: [xri] CID changes in
wd11
... and I just ran out of quarters and dropped from the call :)
Anyway I'm going to read through Drummond's new proposal.. What I still
understood on the call was that it includes a new element (equiv id or
something like that) that simply states identifier synonymity without anything
else, and I like that, since as I said in my other mail the Ref element always
seemed to me to do two different things at the same time (identifier synonymity
AND instructions to the resolver to follow the Ref).
Markus
On 8/16/07, Gabe
Wachob <gabe.wachob@amsoft.net>
wrote:
And I just learned from
my office-mate and from Markus' email that Skype is
down!!!
Ol fashion cell call then ;-)
> -----Original Message-----
> From: Gabe Wachob [mailto:
gabe.wachob@amsoft.net]
> 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
)
|