Title: Re: [xri] CID changes in wd11
Les, regarding your first sentence below (“They are all different resources with a
declaration of synonimty via refs.”), I think Marcus makes a good point when he clarified that sometimes
when we use “XRI authority” we are referring to the “resource
represented by an XRI” and sometimes we are referring to “the resource
descriptor (XRD) to which the XRI resolves”. This leads to a lot of
confusion. The XRI glossary (in XRI Syntax 2.0) is clear that an eXtensible Resource
Identifier identifies a *resource*
and that the resource decriptor format to which an identifier resolves (an
eXtensible Resource Descriptor) is a *descriptor
of the resource*. So we always have these three pieces involved: the
identifier, the resource, and the resource descriptor (which I think of as
standing “between” the identifer and the resource). I think it
would be clearer in these discussions of synonyms if we used these terms instead
of “XRI authority” due to its amibuity about whether you are
referring to a resource or a resource descriptor.
For example, if you apply these terms to
your answer to Bill’s question, “They are all different resources with a declaration of
synonimty via refs.”, the answer doesn’t
make sense. Resources can never be synonymous, only identifiers of resources
can be synonymous.
So, returning to Bill’s questions:
Fred: "@ootao*steven
and =steven.churchill identify the same resource"
Alice: "Prove it"
Fred: ???
Fred: "@ootao*steven and =steven.churchill
identify different resources"
Alice: "Prove it"
Fred: ???
In essence, Bill’s first question is
asking, “Can you prove that two different identifiers from different
identifier authorities identify the same resource?”, and his second is
asking, “Can you prove the same thing in the negative?”
With the CanonicalID-can-be-polyarchical proposal
in ED03, the answer is clearly “Yes” to the first question, and “No”
to the second (in fact I don’t think we’ve ever had an answer to Bill’s
second question, because a lack of synonyms does not necessary mean that two
identifiers don’t identify the same resource.) With the CanonicalID-must-be-hierachical
proposal, the answer to the first question is clearly “Not with a CanonicalID”.
As you point out, if we go the CanonicalID-must-be-hierachical approach, the
question of whether XRI resolution infrastructure should be able to answer Bill’s
first question is one we need to decide as a TC is either in-scope or
out-of-scope.
We’ll take up on tomorrow’s
call. Talk to you then,
=Drummond
From: Chasen, Les
[mailto:]
Sent: Wednesday, August 15, 2007
2:59 PM
To: ;
Cc: ;
; ;
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: <>
To: Barnhill, William <>
Cc: Drummond Reed <>; Steven Churchill
<>; Chasen, Les;
<>; Andy Dale <>
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 <> 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:>
Booz | Allen |
Hamilton
i-name: = Bill.Barnhill
"Delivering results that
endure"
________________________________
From:
<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:>
; 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 <
> 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:]
Sent: Tuesday, August 14, 2007 10:46
AM
To: 'Chasen, Les'; 'Drummond Reed';
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:> ]
Sent: Tuesday, August 14, 2007 12:16
AM
To: Drummond Reed;
<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>
>
pibb me =les/+pibb <http://xri.net/=les/+pibb>
________________________________
From: Drummond Reed [mailto:]
Sent: Tuesday, August 14, 2007 1:37
AM
To: Chasen, Les;
<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>
</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:]
Sent: Monday, August 13, 2007 3:16
PM
To: <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>
>
pibb me =les/+pibb < http://xri.net/=les/+pibb>
