Proposing an OpenID Authentication 2.1 Working Group

David Fuelling sappenin at gmail.com
Tue Nov 11 09:13:55 PST 2008


+1 to Martin's idea.

On Sun, Nov 9, 2008 at 11:19 PM, Martin Atkins <mart at degeneration.co.uk>wrote:

>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openid.net/pipermail/specs/attachments/20081111/ea81b78f/attachment.htm 


More information about the specs mailing list