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

David Recordon recordond at gmail.com
Wed Dec 31 13:57:21 PST 2008


Hi Henrik and Drummond,
After learning more about CX at IIW, I certainly can understand the business
value which is a large part of why I'm trying to help find a way that this
work can occur as a part of OpenID.  That said, I don't think we've been
making a lot of progress on turning the proposal into something that makes
sense as an OpenID Working Group.  I'm certainly happy to have this
discussion via phone and also feel a bit strange about it occurring off the
specs at openid.net list (cc'd at this point) as it touches so much on what
does it mean to be a piece of OpenID.

I agree that it would be valuable to include some use cases (business
oriented or otherwise) in the working group proposals and it would be great
if the CX proposal started to set that precedent (they'll also make it
easier to figure out when the spec is done).

As to Drummond's concern about OpenID turning into the W3C or IETF, I
actully don't think that looking at this process as if it were a standards
body is what we should do.  The W3C, IETF and OASIS all take on a variety of
work that is bounded in one way or another to the Internet.  They work on a
variety of standards, sometimes competing standards, which aren't all used
together nor need to be designed to do so.  OpenID is different from that.

OpenID is much more like Jabber and their process around creating XMPP
Extensions (http://xmpp.org/extensions/).  These extensions, like in the
OpenID world, all need to be a part of XMPP and fit together in one way or
another.  In fact, their site describes the process as:

> The XMPP Standards Foundation <http://xmpp.org/xsf/> (XSF) develops
> extensions to XMPP <http://xmpp.org/> through a standards process centered
> around XMPP Extension Protocols (XEPs). The process<http://xmpp.org/extensions/xep-0001.html>is managed by the XMPP
> Extensions Editor <http://xmpp.org/extensions/editor.shtml> and involves
> intensive discussion on the Standards mailing list<http://mail.jabber.org/mailman/listinfo/standards/>,
> formal review and voting <http://xmpp.org/council/votes.shtml> by the XMPP
> Council <http://xmpp.org/council/>, and modification based on
> implementation experience and interoperability testing.


That is what I'm advocating here.  So no, OpenID shouldn't be like the W3C,
IETF, or OASIS.  It should be more like the Jabber process is for XMPP
Extensions in terms of making sure that the work makes sense as a part of
XMPP, or in our case OpenID.  (Drummond, I'm happy to get on the phone and
talk to you more about this as well since I also realize we're both talking
in broad strokes by making these comparisons.)  The Specifications Council
was actually modeled after the XMPP Council and designed to serve this role.

Since the OpenID specification process is currently designed in such a way
that once a Working Group gets approved, basically anything they create is
called "OpenID" (I raised this issue on the Board mailing list a few weeks
ago http://openid.net/pipermail/board/2008-December/001467.html).  This
means that more scrutiny must be placed upfront to make sure that proposals
make sense as a piece of OpenID unless we want anyone who fills out the form
with a proposal to be call their tech "OpenID" no matter what it does
assuming it's somehow related to online identity.

The alternative process that was proposed, which I support, is separating
getting started from a decision if it makes sense to call the work
"OpenID".  This would then allow a group to come together and develop CX
using OpenID Foundation infrastructure and the IP policy -- with very little
scrutiny -- though not be able to call their specification "OpenID" at that
time.  Rather, once the specification was largely drafted, it could be
submitted to the Specifications Council in a much more complete state where
it's easier to decide if the use cases and technology fit into being a piece
of OpenID.

This isn't a problem for proposals like PAPE, SREG, AX, Discovery, or the
OAuth Hybrid as they're already either a part of OpenID or very clearly
evolve what OpenID is in smaller chunks building upon existing OpenID
technology.  As it stands, I sense significant disagreement within the
community around if the current CX proposal makes sense.

As I said, I'm happy to get on the phone, I continue wanting to find a way
for the CX work to proceed, though don't feel it appropriate for any small
group to radically change what OpenID is as the currently proposed CX work
would do given our current specification development process.

--David

2008/12/31 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 ¨C 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/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openid.net/pipermail/specs-council/attachments/20081231/e9ed3944/attachment-0001.htm 


More information about the specs-council mailing list