Proposing an OpenID Authentication 2.1 Working Group

Mon Nov 10 04:59:46 UTC 2008

I completely agree with Martin's instincts here.

There appear to be two completely orthogonal groups of work items in David's proposal that are in different equivalence classes in terms of maturity, path to completion and current level of agreement.

I see great benefit for the OpenID community in getting the "errata" part out _very quickly_ in order to provide a stabilized base version for implementers, while the "experimental" parts will naturally take longer to work through.

Personally I am indifferent about naming or whether this proposal is refactored into two workgroups, or just one that calls out two separate deliverables on different timescales.
However, I do feel strongly that the "errata" updates need to be expedited in order to try to minimize potential interop issues due to spec interpretation problems going forward, while the "experimental" work can start/proceed in parallel.

- Jorgen

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf Of Martin Atkins
Sent: Sunday, November 09, 2008 3:19 PM
To: specs at openid.net
Subject: Re: Proposing an OpenID Authentication 2.1 Working Group

I'm in favor of working on a new version of OpenID Authentication with
new features, but I think it's also important not to forget about 2.0. I
think we should also publish a minor revision to 2.0 which includes only
the errata and clarifications, not the new features. I'd like to have a
spec to point to that describes today's implementations (bugs
notwithstanding) to help with interop while we're working on the next
big thing.

As an analogy, consider that OpenID Authentication 2.1 is like CSS3 --
it clarifies CSS 2.0, but it also adds new features that mean that it
takes a long time to get published. CSS 2.1 was published in the interim
with the express purpose of describing today's CSS implementations.

This interim spec could either be an additional item published by the
2.1 working group or a separate working group in its own right. The
former will probably be easier, just so that the two groups don't end up
duplicating work.

I'd be great if this interim spec -- let's call it 2.0.1 -- would
require little or no changes to present implementations. It would just
be clarifying the corner cases that cause us interop problems today. It
would therefore hopefully be non-controversial and should be turned
around pretty quickly in comparison to the full 2.1 specification.

Given that the additional items in David's proposal -- email addresses
as identifiers and a new signature scheme -- are largely self-contained
changes, it ought to be possible to work on them as standalone items
while 2.0.1 is being written and then merge them to form 2.1 when the
time comes.

David Recordon wrote:
> OpenID Authentication 2.0 was finalized this past December and since
> has started to see quite reasonable adoption.  Most libraries have
> been updated to support 2.0 and most OpenID Providers support it as
> well (in fact a few such as Google and Yahoo! only support 2.0).
> Since the finalization of Authentication 2.0, numerous errata items
> have been brought up via the OpenID mailing lists (some have already
> been patched in SVN though not released). The community has also
> gained clarity around security needs, current features usage, and
> challenges facing OpenID for more mainstream adoption.
>
> This draft Working Group proposal is designed to produce the next
> version of OpenID Authentication - dubbed 2.1 - while maintaining
> backwards compatibility with OpenID Authentication 2.0 implementations
> already in use. This proposal outline follows the requirements of the
> OpenID IPR Process document (http://openid.net/ipr/OpenID_Process_Document_%28Final_Clean_20071221%29.pdf
> ).
>
> My goal of sending this draft out is to collect feedback prior to and
> at the Internet Identity Workshop this coming week so that we can
> officially create the working group later in the week.  So please,
> take a read, keep in mind that we're not trying to change too much at
> any one time, and let us know what you think.
>
> Thanks,
> --David
>
> Background Information:
> Most of the related work for moving OpenID infrastructure forward is
> occurring outside of the immediate OpenID specifications community:
>   - Projects like XRDS-Simple (http://xrds-simple.net/) are evolving
> the Yadis discovery protocol.
>   - EAUT (http://eaut.org/) among others are looking at email address-
> style identifiers.
>   - The OpenID Foundation is investigating security considerations and
> improvements.
>   - Various groups are working on projects that start to integrate
> OpenID with the browser (http://www.sxipper.com/, https://pip.verisignlabs.com/seatbelt.do
> , http://blog.vidoop.com/archives/163, http://www.eclipse.org/higgins/).
> In addition, since the release of OpenID 2.0, OAuth (http://
> oauth.net/) is now a finalized specification that is gaining adoption
> and has a workflow similar to OpenID Authentication.
>
> Working Group Name:
> OpenID Authentication 2.1
>
> Purpose:
> Correct errata and update the Authentication 2.0 specification based
> upon feedback from public implementations while maintaining backwards
> compatibility with OpenID Authentication 2.0 to the greatest degree
> possible.
>
> Scope:
> The proposed work is as follows:
>   - Perform "bug fixes" of incorrect wording and cleanup wording, add
> diagrams, and if necessary restructure portions of the specification
> to increase the overall readability and uniformity of interpretation.
>   - Apply clear copyright licensing language to the specification in
> addition to noting that is covered by the OpenID Foundation IPR Policy
> Non-Assertion Agreements.
>   - Add a new Appendix containing security guidance for implementers.
> While not intended to be an exhaustive best practices guide, this
> would consolidate in one section the most important guidelines for
> securely implementing OpenID, and would incorporate key lessons
> learned from public implementations.
>   - Clarifying XRDS Based Discovery for URLs possibly by migrating to
> using XRDS-Simple. Note that this requires finalization of XRDS-Simple
> as well as maintaining compatibility with OpenID Authentication 2.0
> implementations.
>   - Clarifying if support of XRI as an identifier type is optional or
> required by Relying Parties and specifying how to use an XRI to take
> full advantage of its usability, security, and privacy properties.
>   - Clarifying whether OPs that support associations over HTTPS are
> required to also support associations using Diffie-Hellman encryption
> over HTTPS connections.
>   - Exploratory work as defined below assuming the Working Group finds
> it feasible to do so.
>
> Exploratory Work:
> The WG will consider the following topics on an exploratory basis to
> include in the specification:
>   - Support for email addresses as OpenID identifiers.  It's been
> shown that identifiers in the form of david at example.com are easier for
> mainstream users to understand, although there are multiple different
> ways to implement this functionality. This has come up many times in
> the past; various technological proposals have been made; and there is
> at least one concrete shipping prototype (EAUT which was based on work
> initiated by David Fuelling http://www.sappenin.com/openid/ext/oet/openid-email-transform-extension-1_0.html)
> . This is similar to a proposal made by Brad Fitzpatrick (http://brad.livejournal.com/2357444.html
> ) that should be explored further with regard to viability of email
> addresses as an identifier type in the OpenID Authentication
> specification. Note that this option may be dependent on large email
> providers showing interest in supporting this style of identifier.
>   - Increasing reuse between OpenID Authentication and OAuth Core.
> Both OpenID Authentication and OAuth Core share a similar protocol
> flow with similar HMAC style cryptographic signing.  OAuth uses a
> slightly different and newer signing mechanism. Changing this in
> OpenID Authentication would break backwards compatibility, but the WG
> should explore the difference(s) and consider adding support for
> OAuth's mechanism alongside the current mechanism for forwards
> compatability.
>
> Anticipated Contributions:
> Specification text from a variety of contributors to achieve the goals
> listed in the above scope.
>
> Proposed List of Specifications:
> OpenID Authentication 2.1. Completion expected within the next six
> months.
>
> Anticipated audience or users of the work:
> Implementers of OpenID Providers and Relying Parties.
>
> Language in which the WG will conduct business:
> English.
>
> Method of work:
> E-mail discussions on the working group mailing list, working group
> conference calls, and possibly a face-to-face meeting at the Internet
> Identity Workshop.
>
> Basis for determining when the work of the WG is completed:
> Proposed changes will be evaluated on the basis of whether they
> increase or decrease consensus within the working group.  The work
> will be completed once it is apparent that maximal consensus on the
> draft has been achieved, consistent with the purpose and scope.
>
> Proposers:
>   - Allen Tom, atom at yahoo-inc.com, Yahoo!
>   - Brad Fitzpatrick, brad at danga.com, Google
>   - Breno de Medeiros, breno at google.com, Google
>   - Carl Howells, chowells at janrain.com, JanRain
>   - David Recordon, drecordon at sixapart.com, Six Apart
>   - Drummond Reed, drummond.reed at parityinc.net, Parity/Cordance/OASIS
>   - Gabe Wachob, gabe at wachob.com
>   - Gary Krall, gkrall at verisign.com, VeriSign
>   - John Bradley, jbradley at mac.com
>   - Johnny Bufu, johnny.bufu at gmail.com
>   - Joseph Smarr, jsmarr at plaxo.com, Plaxo
>   - Josh Hoyt, josh at janrain.com, JanRain
>   - Mart Atkins, matkins at sixapart.com, Six Apart
>   - Max Engel, mengel at myspace.com, MySpace
>   - Scott Kveton, kveton at vidoop.com, Vidoop
>
> Initial Editors:
>   - David Recordon, drecordon at sixapart.com, Six Apart
>   - John Bradley, jbradley at mac.com
>
>
>
>
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs