OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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]