[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.
Drummond, I’ve extracted the text below from
WD11 ED04 regarding EquivID. I don’t see anywhere any mention that this
element is intended to “allow” authority B to use the CanonicalID
of authority A – i.e., that this element is the backpointer construct for
CanonicalEquivID. If your intention is to allow this element
to have “other semantics” (besides the “allow use CID”
i.e, CanonicalEquivID backpointer semantics) then I will tell you again
that you cannot overload semantics in this fashion. The resolver has no way to
determine which semantics to apply. Consider this basic security vulnerability.
Authority A decides it wants to use EquivID to refer to some XRI resolvable
identifier. It has some “other semantics” in mind for this pointer—that
is, semantics other than the CanonicalEquivID backpointer semantics. Now say
the EquivID references authority B. Authority B can now specify CanonicalEquivID
back to authority A and thus trick the Resolver into verifying that authority A
has allowed authority B to use its CID. ~ Steve 5.2.3
EquivID
In XRD documents, a polyarchical global synonym is asserted using the xrd:EquivID
element. This may be used to assert: ·
Other hierachical global synonyms
for the target resource besides the CanonicalID. The final local synonym in all
such identifiers MUST be assigned by the parent authority and SHOULD match a
LocalID asserted in the same XRD. ·
Polyarchical global synonyms for
the target resource that are NOT assigned by the parent authority. An EquivID MUST be an absolute identifier. For durability of the
reference, it is RECOMMENDED to use a persistent identifier such as a
persistent XRI [XRISyntax] or a URN [RFC2141]. If an EquivID will be used to establish equivalence of identity across
trust domains, it SHOULD be verified. This function is not performed
automatically by XRI resolvers during resolution but may be easily performed by
consuming applications using one additional XRI resolution call. See section 13.5. A parent authority SHOULD NOT permit a child authority to edit the EquivID value in
an XRD without authenticating the child authority and verifying that the child
authority is authorized to use this EquivID value. From: Drummond Reed
[mailto:drummond.reed@cordance.net] 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. 1.
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]