[OIDFSC] FW: Proposal to create the TX working group

Tue Jan 13 08:51:22 UTC 2009

Thanks, and a call would be a good thing.  I'd also like to continue this
discussion on the specs at openid.net mailing list for a larger technical
audience to participate in the review and refinement of the proposal since
there doesn't yet seem to be consensus around this work.

--David

On Tue, Jan 13, 2009 at 12:44 AM, Nat Sakimura <sakimura at gmail.com> wrote:

> Since it is easy to go back in versions (thanks to the wiki!), I have
> created stripped down version of the proposal.
>
> http://wiki.openid.net/Working_Groups%3AContract_Exchange_1
>
> Please have a look.
>
> =nat
>
>
> On Tue, Jan 13, 2009 at 5:15 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
>> Tatsuki,
>>
>> Could you kindly set-up a followup call, please?
>>
>> In the mean time though, I would like to ask spec council members for the
>> response towards the answers given by the proposers to your concerns. Any
>> concrete suggestion to make it acceptable to the spec council is also
>> welcome. It's a wiki, after all.
>>
>> As to the "community support", it would probably depend on what
>> "community".
>> The proposers are probably talking of higher value transaction users, and
>> if we do it in timely manner, I am pretty confident that it will have some
>> traction, but it needs to happen fast. If we take too much time, the
>> opportunity will go away from OpenID.
>>
>> =nat
>>
>> 2009/1/1 Drummond Reed <Drummond.Reed at parityinc.net>
>>
>>  David,
>>>
>>>
>>>
>>> First, I agree with Henrik's comments (see his separate email). Second,
>>> to say, "I do not believe that it currently has sufficient support within
>>> the OpenID community to succeed", did you see the list of proposers for this
>>> workgroup?
>>>
>>>    - Drummond Reed, drummond.reed at parity.com, Cordance/Parity/OASIS
>>>    (U.S.A)
>>>    - Henrik Biering, hb at netamia.com, Netamia (Denmark)
>>>    - Hideki Nara, hdknr at ic-tact.co.jp, Tact Communications (Japan)
>>>    - John Bradeley, jbradley at mac.com, OASIS IDTrust Member Section
>>>    (Canada)
>>>    - Mike Graves, mgraves at janrain.com, JanRain, Inc. (U.S.A.)
>>>    - Nat Sakimura, n-sakimura at nri.co.jp, Nomura Research Institute,
>>>    Ltd.(Japan)
>>>    - Robert Ott, robert.ott at clavid.com, Clavid (Switzerland)
>>>    - Tatsuki Sakushima, tatsuki at nri.com, NRI America, Inc. (U.S.A.)
>>>    - Toru Yamaguchi, trymch at gmail.com, Cybozu Labs (Japan)
>>>
>>> In short, my first reaction to reading your email was to think, "Wow,
>>> here it is, the first example of OpenID turning into W3C and IETF and every
>>> other standards organization that turns into a small group of insiders
>>> trying to control innovation!"
>>>
>>>
>>>
>>> Of course I think you, more than almost anyone, can appreciate the irony
>>> of that thought - I believe it was to avoid that very situation that the
>>> OIDF was created, no?
>>>
>>>
>>>
>>> So if we DON'T want that to happen, I think what we need to do ASAP is
>>> turn this into a constructive dialog between the proposers of this Working
>>> Group and the Specs Council about how the charter might be amended to addess
>>> some of your concerns. (I'm not commenting yet on your specific concerns,
>>> other than to say that I agree with some and not with others.)
>>>
>>>
>>>
>>> I suspect email is going to be much too slow for such a dialog, so I
>>> would suggest that Nat and Tatksuki set up a telecon between the Working
>>> Group proposers and the Specs Council members. I would also suggest that
>>> before such a telecon, the Specs Council get together and collectively list
>>> their issues with the Charter on the Working Group Charter page. I have
>>> added a section for this purpose:
>>>
>>>
>>>
>>>
>>> http://wiki.openid.net/Working_Groups%3AContract_Exchange_1#cSpecificationCouncilIssues
>>>
>>>
>>>
>>> It may be that all the Specs Council members agree with your four points
>>> below, in which case you can just wholesale copy them into the wiki page.
>>> However it is very important that the Specs Council come to it's own
>>> consensus about the issues it has with the charter, because without that,
>>> the WG proposers have no hope of addressing these issues, either with
>>> counterarguments or with potential amendments.
>>>
>>>
>>>
>>> Listing the issues there also enables us to have a more focused
>>> discussion than email alone by using comments directly on the wiki page.
>>>
>>>
>>>
>>> =Drummond
>>>
>>>
>>>   ------------------------------
>>>
>>> *From:* David Recordon [mailto:recordond at gmail.com]
>>> *Sent:* Wednesday, December 31, 2008 12:33 AM
>>> *To:* Nat Sakimura
>>> *Cc:* specs-council at openid.net; Josh Hoyt; Tatsuki Sakushima; John
>>> Bradley; hdknr at ic-tact.co.jp; Robert Ott; Michael Graves; Henrik
>>> Biering; Drummond Reed; Nat Sakimura; 山口徹
>>>
>>> *Subject:* Re: [OIDFSC] FW: Proposal to create the TX working group
>>>
>>>
>>>
>>> Hi Nat,
>>>
>>> I read Josh's email as agreeing with Mike's statement of:
>>>
>>> The OpenID Specifications Council recommends that members reject this
>>> proposal to create a working group because the charter is excessively broad,
>>> it seems to propose the creation of new mechanisms that unnecessarily create
>>> new ways to do accomplish existing tasks, such as digital signatures, and it
>>> the proposal is not sufficiently clear on whether it builds upon existing
>>> mechanisms such as AX 1.0 in a compatible manner, or whether it requires
>>> breaking changes to these underlying protocols.
>>>
>>>
>>> While you have clarified that you don't intend to create a new XML
>>> signature mechanism, OAuth describes a mechanism to use public keys to sign
>>> these sorts of parameters.  Signatures aside, as Mike said other aspects of
>>> the charter seem quite broad and it is unclear how it will build upon AX 1.0
>>> and other underlying existing OpenID technologies.
>>>
>>> Given the draft charter at
>>> http://wiki.openid.net/Working_Groups%3AContract_Exchange_1:
>>> 1) The purpose of producing a series of extensions seems too broad.
>>> OpenID was born on the idea of doing one simple thing and we've seen success
>>> with OpenID and related technologies when they are made up of small pieces
>>> loosely joined.  OpenID Authentication 2.0 broke this rule in some areas and
>>> we're now seeing the repercussions of doing so.
>>>
>>> 2) In what jurisdictions are these contracts legally binding?  Is
>>> "arbitrary parties to create and exchange a mutually-digitally-signed
>>> legally binding 'contract'" a justifiable statement or should it be toned
>>> down?  It should also be kept in mind that since OpenID's creation it has
>>> been very clear that OpenID does not provide trust, but rather trust can be
>>> built on top of identity.  I'm not saying that OpenID should never deal with
>>> trust, just trying to understand if this Working Group intends to change how
>>> OpenID currently does not create this form of trust.
>>>
>>> 3) The purpose says that the Working Group intends to possibly extend AX
>>> and create a series of specifications.  It does not seem prudent to give a
>>> Working Group the ability to arbitrarily extend an existing extension or
>>> create an unlimited number of specifications.
>>>
>>> 4) The Scope section is still not clear as to what the Working Group will
>>> actually be producing.  I would prefer to see the section rewritten, maybe
>>> mimicking the structure currently being considered for the specification.
>>>
>>> As to if you wish to force this proposal forward, I do not believe that
>>> it currently has sufficient support within the OpenID community to succeed
>>> and that its broad scope contravenes the community's purpose.  This is why
>>> I'm really hoping that the proposal can be refined to something which will
>>> be successful that a broad community can get behind!
>>>
>>> --David
>>>
>>>
>>>
>>> On Tue, Dec 30, 2008 at 9:03 PM, Nat Sakimura <sakimura at gmail.com>
>>> wrote:
>>>
>>> Hi Josh,
>>>
>>>
>>>
>>> To which statement did you agree?
>>>
>>>
>>>
>>> There has been a several things that has been pointed out, but I think I
>>> have answered to them.
>>>
>>>
>>>
>>> For example, for XML Sig, I have stated that this spec is not for XML,
>>> etc.
>>>
>>> For modularization, yes, that is a possibility but a scope needs to be
>>> able to cover a field that it requires, even if it ends up not covering that
>>> field.
>>>
>>> It is impossible to widen the scope though narrowing it down at a later
>>> date is easy.
>>>
>>>
>>>
>>> Unfortunately, I have not heard back any concrete response
>>> for amendments. It would be more constructive to have those.
>>>
>>>
>>>
>>> Also, if you are giving advise to the membership an recommendation for
>>> not approving it, you need to state the reasons concretely.
>>>
>>>
>>>
>>> It needs to be one of
>>>
>>>
>>>
>>> (a)    an incomplete Proposal (i.e., failure to comply with §4.1);
>>> (b)    a determination that the proposal contravenes the OpenID
>>> community's purpose;
>>> (c)    a determination that the proposed WG does not have sufficient
>>> support to succeed
>>>
>>>          or to deliver proposed deliverables within projected completion
>>> dates; or
>>> (d)    a  determination that the proposal is likely to cause legal
>>> liability for the OIDF or others.
>>>
>>>
>>>
>>> and should state why the proposal falls into one of the criteria
>>> concretely and accountably.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> =nat
>>>
>>>
>>>
>>> On Wed, Dec 31, 2008 at 7:58 AM, Josh Hoyt <josh at janrain.com> wrote:
>>>
>>> On Tue, Dec 30, 2008 at 12:17 PM, Mike Jones
>>>
>>> <Michael.Jones at microsoft.com> wrote:
>>>
>>> > I realize it was Christmas week but it's been a week and we've heard
>>> nothing
>>> > from any of the other specs council members on this proposal (or the
>>> other
>>> > one as well).
>>>
>>> I agree with the statement that you made about this proposal.
>>>
>>> Josh
>>>
>>>
>>>
>>>    --
>>> Nat Sakimura (=nat)
>>> http://www.sakimura.org/en/
>>>
>>>
>>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20090113/86fcb3c0/attachment-0002.htm>