Proposing an OpenID Authentication 2.1 Working Group

David Recordon drecordon at sixapart.com
Sat Nov 8 10:47:42 PST 2008


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








More information about the specs mailing list