[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] EquivID and CanonicalEquivID need to be dropped from spec.
|
Steve, First, I’d like to make an observation
I’ve mentioned several time before: I find the tone of some of your
messages to the list abrasive to the point of – from the standpoint of myself
as the recipient – feeling insulting. I don’t know if you mean it that
way, but it feels that way to me. I honestly don’t believe the
discourse we are holding on a publicly archived mailing list about a technical
standard needs to include perjorative content or personal attacks. To be
specific, following are quotes from your message: * “Retroactively
concoct use cases to support the two artifact constructs, and leave them in the
spec. (It's almost as though we would be leaving them in just to justify the
time the TC spent working on the use case.)” * “Drummond decided that XRI resolution could also
benefit from this new feature, so the new requirement was born.” * “The TC needs to by crystal clear about why new
constructs are being added to the spec. It should not be going down one track
to solve a given use case and then littering the specification with artifacts.” * “The ship for this use case has long sailed.” Steve, if you believe that for some reason
I or anyone else on the TC is motivated to include a feature in XRI resolution
that does not address a legitimate use case, or does not have technical merit,
please speak your mind. But the statements you make above go well beyond that;
from my reading they are accusing me and the other editors of acting in bad
faith. Besides the fact that I believe anyone would
be offended by such an accusation, particularly when it is taking place in a
publicly archived mailing list at a major Internet standards body, what I find
particularly upsetting about this is that you make it sound as if I am acting
against the majority opinion of the TC. Which is especially ironic in this case
because when I “scribed” the new synonym sections in ED04 (a small
matter of over twelve hours of intensive writing/editing work), I was
faithfully recording the consensus of the editors as reflected not only the mailing
list, but from a special call held on this topic on Monday August 24th: http://lists.oasis-open.org/archives/xri/200708/msg00096.html The conclusion of this call, which you did
not attend, was that I was to proceed with writing up ED04 according to the
proposal listed at… http://wiki.oasis-open.org/xri/XriCd02/SynonymSemantics …which had been discussed on the
list extensively the prior few days and which, with the exception of one typo,
has not changed since that date: http://wiki.oasis-open.org/xri/XriCd02/SynonymSemantics?action=info Now, with that said, please read very
closely my inline response to your specific points below, because what it
indicates to me is that either you didn’t fully read the ED04 spec, or
you didn’t understand it (which could possibly be my fault). From: Steven Churchill
[mailto:steven.churchill@xdi.org] Two new constructs EquivID and CanonicalEquivID have been
added to WD11 in an attempt to satisfy a use case that Drummond introduced in
May. The new constructs, however, do not satisfy the original use case. As
such, they need to be removed from the spec. Here is a rough timeline of the events. a) XRI Resolution 2.0 WD10 remains unchanged from the
Spring, 2006 while TC works on other stuff. b) In May, 2007, TC decides to resume work on
Resolution 2.0 in order to close it. WD11 begins. c) In May, 2007, Drummond introduces new use case
"OpenID recycling problem" that he wants XRI Resolution to solve. [=Drummond] Steve, you make it sound like
I am the only one on the TC who was motivated to solve this use case. Do you
really believe that’s true? Yes, I am an active board member of the OpenID
Foundation (see http://openid.net/wiki/index.php/OpenID_Foundation),
and I believe that it is very important for XRI adoption for XRI to
interoperate with and be part of OpenID, but Gabe is also very active in
assisting with OpenID, and many others on the TC have been involved in helping
move OpenID forward. d) May--August, 2007: TC goes through process to
change Resolution Spec in order to satisfy the use case from (c). [=Drummond] Steve, you also make it sound
like this is the only issue that was being worked on for a four month time
frame. As you are aware, in July you pulled back from actively participating as
an editor due for reasons you explained privately a message to the other
editors. So since that time, you have not been closely involved with the entire
set of issues that have been dealt with. However the complete set has always
been tracked at… http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11 …and includes a total of 51
different open issues and revisions, of which synonyms and CanonicalID
verification constitute 4, i.e., less than 10% of the entire job. The process in step (d) culminated in WD11, ED04 delivered
last Wednesday. This contains EquivID and CanonicalEquivID both introduced in
attempt to satisfying the use case in step (c). The problem is that THEY DO NOT
SATISFY THE USE CASE (as I explain below.) These constructs are nothing but
artifacts from the process in step (d). [=Drummond] I could not disagree more. See
my inline responses to part two of your message below. The TC is now confronted with two choices: 1) Since the 3+ month process in step (d) did not result in
solving the original use case, acknowledge that the use case may not have been
all that important, and drop the artifacts from the specification. 2) Retroactively concoct use cases to support the two
artifact constructs, and leave them in the spec. (It's almost as though we
would be leaving them in just to justify the time the TC spent working on the
use case.) This kind of stuff is fundamental and very important! The TC
needs to by crystal clear about why new constructs are being added to the spec.
It should not be going down one track to solve a given use case and then littering
the specification with artifacts. The TC needs to bring this issue to a vote. [=Drummond] We are about to bring the
entire specification to a vote. ~ Steve In this section, I explain why the two new constructs do not
satisfy the original use case presented in step (c). In part 2 of my previous 3
part email, I described the use case. Here it is again: The original use case: It started with a thread on the OpenID list was discussing
the “recycling” problem: say John loses his OpenID (URL) and the
later Fred acquires it. Fred can go around to all the RPs where John had
established accounts and effectively “hijack” John’s
accounts. Some sort on non re-assignable identifier was needed. If the RPs
instead stored the non re-assignable identifier, then John would not need to
worry about ever losing his accounts—even if he loses his OpenID
identifier. So the proposal went like this: given an OpenID URL, YADIS
metadata discovery would return an XRD containing the OpenID endpoint but now
it would contain a new construct telling the client RP “go ahead and use
the OpenID OP endpoint specified within this metadata, but instead of using the
OpenID URL as your account’s PK, use this other non re-assignable
identifier instead”. There would also need to be a mechanism to allow for
the verification that the non re-assignable identifier had been provisioned to
allow the OpenID URL to use it. An XRI client would perform resolution and get back the XRD,
and now a new element would indicate “go ahead and use the metadata in
this XRD (such as the service endpoints) but if you are interested in using the
identity of this authority, then please use CanonicalID indicated in this new
element (rather than using the value in the original CanonicalID element.) XRI
resolution would need to support a mechanism where a client could confirm that
the second authority had “allowed” the first authority to use its
identity. (Thus the reason for my originally proposing the “UseCID”
and “AllowUseCID” constructs.) [=Drummond] Steve, your explanation doesn’t
distinguish the fact that the overall use case of solving the “OpenID recycling
problem” by verifying the binding between the original query identifier
and a canonical identifier involves two more specialized use cases: 1) Verifying the binding when the query
identifier and canonical identifier are both issued by the SAME identifier authority
and 2) Verifying the binding when the query
identifier and canonical identifier are issued by DIFFERENT identifier authorities. Neither use case was supported in WD10.
The TC addressed this by working out last fall (after invaluable input from OpenID
implementers and editors and specifically Kevin Turner at JanRain) a new proposed
feature for WD11 called CanonicalID verification. You were one of the editors most
involved in the architecture of that feature. Subsequent feedback from the OpenID community
received after the Internet Identity Workshop in early May 2007 revealed that CanonicalID
verification, as we had defined it, only addressed the first use case above
(when both the query identifier and the canonical identifier are issued by the
same authority), and not the second (when they are issued by different
identifier authorities). That’s when work began to figure out how to most
efficiently address the second use case. That work DID take a long time because
initially there was not consensus on the TC about: a) whether the use case was
important enough, and b) how to accomplish it. (See part two of my previous email for further discussion of
this stuff.) Why the two existing constructs don’t
support the original use case: Simple. The proposal in last Wednesday in WD11 ED04 has no means
for a Resolution client to verify that the second authority had
“allowed” the first authority to use its identity. It thus does not
satisfy the original use case. (No more needs to be said.) [=Drummond] Steve, in all honesty I can
only say that either you didn’t read the new sections of ED04 (sections 5
and 13), or that for some reason you misunderstood them. Since, as a specification editor, I take
the clarity and understandability of the spec very seriously, and I spent at
least double the time I expected to make sure these new sections were as clear
as possible, following is the entire text of the section that specifies the “means for a
Resolution client to verify that the second authority had “allowed”
the first authority to use its identity”. TO BE EXTREMELY PRECISE, I will point out that the term “identity”
does NOT appear in the spec, only the term “identifier”, so what
the following section actually does is provide a “means for
a Resolution client to verify that the second authority had
“allowed” the first authority to use its CanonicalID identifier”. ****** BEGIN EXCERPT ******** 13.2 CanonicalEquivID Verification
CanonicalID verification also requires verification of a
CanonicalEquivID but only if it is present
in the final XRD in the resolution chain. Since CanonicalEquivID
verification requires an extra resolution cycle, restricting automatic verification
to the final XRD in the resolution chain ensures it will add at most one additional
resolution cycle. To verify that either an HTTP(S) URI or an XRI is a valid hierachical
CanonicalEquivID synonym for a query identifier, an XRI resolver MUST verify
that all the following tests are successful: 1.
CanonicalID verification as
specified in section 13.1 MUST have completed successfully. 2.
The asserted CanonicalEquivID
value MUST be an HTTP(S) URI or XRI and MUST successfully resolve per the rules
in this specification. 3.
The final XRD in the resolution
chain MUST contain a xrd:XRD/xrd:EquivID
element whose value is equivalent to the value of the verified xrd:XRD/xrd:CanonicalID
element in the XRD asserting the CanonicalEquivID synonym. See section 5.2.4 for recommendations regarding provisioning of an xrd:XRD/xrd:EquivID element in an
XRD. ******** END EXCERPT ********** [=Drummond] I should point out that this fundamental
mechanism for verifying a cross-authority synonym – by confirming the
existence of a backpointer – has not changed since it was first proposed
last May. In fact there were three demonstrations of precisely this same
fundamental mechanism being used to verify relationships in “the social
graph” across different social networks at the Data Sharing Summit (http://datasharingsummit.com) this
past Friday and Saturday. So it wasn’t the mechanism the TC was grappling
with in July and August, it was the semantics of the elements that would be
used to: a) assert the forward pointer to another CanonicalID, and b) provide
the backpointer authorizing the assertion. But I believe the final result in ED04
is clear as a bell: a) CanonicalEquivID is the asserted forward pointer, and b)
EquivID is the backpointer providing authorization. Any constructs left over (i.e., EquivID and CanonicalEquivID)
are just artifacts of the process in step (d) above. These constructs have not
been motivated by an initial use case, and they need to be dropped from the
spec. [=Drummond] Again, Steve, it is writing
like this that I personally find abrasive, if not insulting – and in this
case not just to me but to the other three active XRI Resolution editors (Les,
Wil, and Gabe). If you had read ED04 carefully, and followed the list and wiki
traffic, you would know that EquivID is in fact a synonym element that, to the
best of my knowledge, has complete consensus on the TC because: a) Starting in ED03 the cardinality of the
CanonicalID element became zero-or-one, so another synonym element was needed to
order for an identifier authority to assert other global synonyms (see the
precise definition of that term in Section 5 of ED04) for the query identifier.
In ED03 that synonym element was called GlobalID, and in ED04 GlobalID was
dropped in favor of EquivID. b) Secondly, in ED04, by unanimous consensus
of the active editors, the semantics of the Ref element were restricted to
purely XRDS equivalence mapping (*not* identifier equivalence mapping). This
provide a second strong motivation to add a synonym element whose semantics
were clearly and unambigously an assertion of equivalence between the query
identifier and another global identifier BESIDES the CanonicalID. EquivID is
that element. The supreme irony of this message is that the
other new synonym element in ED04, CanonicalEquivID, is essentially –
with the exception of the actual name of the element itself – EXACTLY the
element you originally suggested calling “UseCID”. The editors
simply concluded that since we already had a CanonicalID element and an EquivID
element, the term CanonicalEquivID would be the clearest and most semantically
unambiguous. In addition, what you may not have
understood is that the editors concluded that, since there was already
consensus on the semantics of EquivID, there was no reason to add yet another synonym
element (we were already up to five) for CanonicalEquivID authoritization. We agreed
that since the semantics of EquivID are an UNAMBIGUOUS ASSERTION OF SYNONYMITY
BETWEEN TWO GLOBAL IDENTIFIERS, it was wholly sufficient for an authority to
publish an EquivID element (pointing to the CanonicalID of a second authority)
to authorize the second authority to publish an CanonicalEquivID element (pointing
to the CanonicalID of the first authority). I anticipate that Drummond's response will be either (i) to
retroactively provide use cases to justify the artifact constructs, [=Drummond] No. or (ii) to modify the constructs so that they do satisfy the
use case. [=Drummond] No. As for (i) any use cases should have been presented at time
(c) in the timeline. As for (ii) it is Drummond's own pen that scribed the
proposal in WD11 ED04, and that was after 3+ months working on the solution.
Since the constructs don't satisfy the use case, this has to be an
acknowledgement that the use case was not that important. [=Drummond] No. The ship for this use case has long sailed. [=Drummond] Steve, after what I have spent
90 minutes of my Sunday evening documenting here, I frankly believe you owe not
just me, but the entire XRI resolution editors team an apology. Again, the
supreme irony here is that, three months after you suggested it in a
conversation with me, the TC ended out adopting the crux of your suggestion
about how to handle cross-authority verification of a query identifier-to-canonical
identifier binding. I mentioned this to Andy Dale at the Data Sharing Summit on
Friday (please do ask him). On the other hand, it is entirely possible
that either: a) my writeup of the CanonicalEquivID verification in ED04 was so
poor or misleading that you didn’t understand it, or b) that I (and the
other XRI resolution editors) have missed some deeper technical flaw that
renders this solution untenable. If either is the case, you have my apology
in advance for pushing back so hard. Either way, let me reiterate what I have
said before, which is that whenever you have an issue like this – above all
one which my lead you to believe myself or some other member of the TC may be
acting in bad faith – please don’t hesitate to pick up the phone
and call that person. Direct conversations can be so much more effective at
resolving issues like this. =Drummond |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]