I agree … we should only need
equivId.
Let me add, just to get it out there …
I am generally ok with adding this new tag but I fear that there are some
nuances that will not get uncovered because we are out of time to really think
about this from all angles.
contact: =les
voice: =les/(+phone)
chat: =les/skype/chat
pibb me =les/+pibb
From: [mailto:] On Behalf Of Markus Sabadello
Sent: Monday, August 20, 2007
11:37 AM
To: Tan,
William
Cc: Chasen, Les; Drummond Reed;
Gabe Wachob; Davis, Peter; William
Barnhill; ; XRI TC; Andy Dale
Subject: Re: [xri] ED04 synonym
proposal (was RE: [xri] CID changes in wd11)
I see it the other way round.. I think MapFromID / MapToID is unnecessary,
because you can do everything just with the EquivID.
And why should it not be enforcable? You just look for a matching EquivID in
the second XRD.
Markus
On 8/20/07, Tan, William <> wrote:
I agree with Les. It
seems to me that we have the following:
Ref - resolution semantics only
EquivID - equivalence/synonymity semantics only (non-enforceable)
MapToID - equivalence/synonymity semantics enforceable by resolution
MapFromID - used as an explicit permission granting in order to support
MapToID. A MapFromID will not be acted upon by the resolution client if
it was not trying to verify a MapToID.
It seems to me that EquivID is almost redundant, if one could express
weak synonymity using a MapToID without the corresponding MapFromID.
=wil
Chasen, Les wrote:
>
> I do like the separation from existing attributes better. I am
not
> sure I see a strong enough reason for there to be an equivId and
> MapToId. The proposal equates mapToId to an http 301 permanent
> redirect. I am not sure that is a valid parallel to
draw. There is
> nothing in the proposal that makes the XRD that contains the mapToId
> to not be used as one normally is used.
>
>
>
> contact: =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>
>
> pibb me =les/+pibb <
http://xri.net/=les/+pibb>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:*
[mailto:]
> *On Behalf Of *Markus Sabadello
> *Sent:* Saturday, August 18, 2007 4:27 PM
> *To:* Drummond Reed
> *Cc:* Gabe Wachob; Davis, Peter;
Chasen, Les; William Barnhill;
> ;
XRI TC; Andy Dale
> *Subject:* Re: [xri] ED04 synonym proposal (was RE: [xri] CID changes
> in wd11)
>
>
>
>
> Having missed most of the TC call, I don't know what other peoples'
> opinions are, but here's mine:
> I like the EquivID, because it's easy to understand, has only one
> meaning, and because it's symmetrical. The separation of "resolution
> equivalence" (Ref) and "identification equivalence"
(EquivID) sounds
> very useful to me from a practical standpoint, although it would be
> interesting to hear Steven's opinion about it.
>
> I would expect that EquivID be used much more often than Ref, or both
> at the same time.
>
> I am not so sure about the MapToID / MapFromID.. What's the purpose of
> that? I think I understand how it works, but what would be an example
> for a use case in which the EquivID wouldn't be good enough?
>
> Markus
>
> On 8/16/07, *Drummond Reed* <
> <mailto:>>
wrote:
>
> 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:*
<mailto:>
> [mailto:
> <mailto:>]
*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;
>
<mailto: >;
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* <
> <mailto:>>
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:
> <mailto:>]
> > Sent: Thursday, August 16, 2007 10:04 AM
> > To: 'Peter Davis'; 'Drummond Reed'; 'Les Chasen';
> >
<mailto:>;
'William
> Barnhill'
> > Cc:
<mailto:>;
'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:
> <mailto:
>]
> > > Sent: Thursday, August 16, 2007 5:51 AM
> > > To: Drummond Reed; Les Chasen;
> <mailto: >;
William
> > Barnhill
> > > Cc:
<mailto: >;
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" <
> <mailto:>>
> > 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:
> <mailto:>]
> > > > Sent: Wednesday, August 15, 2007 2:59 PM
> > > > To:
<mailto:>;
>
<mailto: >
> > > > Cc:
> <mailto:
>;
> <mailto:>;
> > > >
<mailto:>;
> <mailto: >
> > > > 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
<http://xri.net/=les.chasen >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From:
> <mailto: >
<
> <mailto:
>>
> > > > To: Barnhill, William <
> <mailto:
>>
> > > > Cc: Drummond Reed <
> <mailto:
>>; Steven Churchill
> > > > <
<mailto:>>;
> Chasen, Les;
<mailto:>
> > > > <
<mailto:>>;
> Andy Dale <
<mailto: >>
> > > > 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 <
> <mailto:>>
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:
> > >
<mailto: >
> > > > <mailto:
<mailto:>>
> > > > Booz |
Allen | Hamilton
i-name: = Bill.Barnhill
> > > >
"Delivering results that endure"
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
________________________________
> > > >
> > > > From:
> <mailto:
>
> > > <mailto:
<mailto:>>
> > > > [mailto:
> <mailto:>
> > <mailto:
<mailto:>>
> > > ] On
> > > > Behalf Of
Markus Sabadello
> > > > Sent:
Wednesday, August 15, 2007 3:57 PM
> > > > To:
Drummond Reed
> > > > Cc: Steven
Churchill; Chasen, Les;
>
<mailto: >
> > > > <mailto:
> <mailto:
>> ; 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 <
> <mailto:>>
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:
<mailto: >]
> > >
>
Sent: Tuesday, August 14, 2007 10:46 AM
> > >
>
To: 'Chasen, Les'; 'Drummond Reed'; -
> > > open.org <http://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:
> > >
<mailto:>
> > > > <mailto:
<mailto:>>
]
> > >
>
Sent: Tuesday, August 14, 2007 12:16 AM
> > >
>
To: Drummond Reed;
> <mailto:>
> > > > <mailto:
<mailto:>>
> > >
>
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>
> > > > <http://xri.net/=les/skype/chat>
>
> > > >
> > >
>
pibb me =les/+pibb < http://xri.net/=les/+pibb>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
>
________________________________
> > > >
> > >
>
From: Drummond Reed
> > > > [mailto:
> <mailto:>]
> > >
>
Sent: Tuesday, August 14, 2007 1:37 AM
> > >
>
To: Chasen, Les;
> <mailto:>
> > > > <mailto:
<mailto:>
>
> > >
>
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
> <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> <
> 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>
> > > > <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:
<mailto:>]
> > >
>
Sent: Monday, August 13, 2007 3:16 PM
> > >
>
To:
> <mailto:>
> > > > <mailto:
<mailto:>>
> > >
>
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>
> > > > <http://xri.net/=les/skype/chat>
>
> > > >
> > >
>
pibb me =les/+pibb < http://xri.net/=les/+pibb>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > =peterd ( http://xri.net/=peterd
)
>
>
>
>
>
