[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: EquivID and CanonicalEquivID need to be dropped from spec.
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. d) May--August, 2007: TC goes through process to
change Resolution Spec in order to satisfy the use case from (c). 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). 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. ~ 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. Drummond decided that XRI resolution could also benefit from
this new feature, so the new requirement was born. 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.) (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.) 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. I anticipate that Drummond's response will be either (i) to
retroactively provide use cases to justify the artifact constructs, or (ii) to
modify the constructs so that they do satisfy the use case. 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.
The ship for this use case has long sailed. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]