+1 to Martin's idea. On Sun, Nov 9, 2008 at 11:19 PM, Martin Atkins <[EMAIL PROTECTED]>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 [EMAIL PROTECTED] 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, [EMAIL PROTECTED], Yahoo! > > - Brad Fitzpatrick, [EMAIL PROTECTED], Google > > - Breno de Medeiros, [EMAIL PROTECTED], Google > > - Carl Howells, [EMAIL PROTECTED], JanRain > > - David Recordon, [EMAIL PROTECTED], Six Apart > > - Drummond Reed, [EMAIL PROTECTED], Parity/Cordance/OASIS > > - Gabe Wachob, [EMAIL PROTECTED] > > - Gary Krall, [EMAIL PROTECTED], VeriSign > > - John Bradley, [EMAIL PROTECTED] > > - Johnny Bufu, [EMAIL PROTECTED] > > - Joseph Smarr, [EMAIL PROTECTED], Plaxo > > - Josh Hoyt, [EMAIL PROTECTED], JanRain > > - Mart Atkins, [EMAIL PROTECTED], Six Apart > > - Max Engel, [EMAIL PROTECTED], MySpace > > - Scott Kveton, [EMAIL PROTECTED], Vidoop > > > > Initial Editors: > > - David Recordon, [EMAIL PROTECTED], Six Apart > > - John Bradley, [EMAIL PROTECTED] > > > > > > > > > > > > > > _______________________________________________ > > specs mailing list > > specs@openid.net > > http://openid.net/mailman/listinfo/specs > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs