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 Working Group 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.
Status
Pending community review before being submitted to the Specfications Council and Foundation Membership for approval.
Background Information
Most of the related work for moving OpenID infrastructure forward is occurring outside of the immediate OpenID specifications community:
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. Two areas of focus are delegation and error handling.
- 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 referencing a living document (to be edited by Allen Tom) containing security guidance for implementers. Though his document is not intended to be an exhaustive best practices guide, it would consolidate in one section the most important guidelines for securely implementing OpenID, and would incorporate key lessons learned from public implementations.
- Discovery
- Clarifying XRDS-Based Discovery for URLs possibly by migrating to using XRD 1.0. Note that this requires finalization of XRD 1.0 as well as maintaining compatibility with OpenID Authentication 2.0 implementations.
- Adding the ability for a RP to advertise the types of identifiers that it supports.
- Adding the ability for a RP to discover if an OP supports the checkid_immediate mode.
- Consider adding ability for a User to advertise multiple OP's per Identifier (see OpenID Discovery)
- Consider adding ability for a User to specify two-header auth (see OpenID Discovery)
- 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.
- Clarifying if RPs are allowed to whitelist and/or blacklist supported OPs and vice-versa.
- Clarifying if IRIs are a supported identifier type.
- 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:
- 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.
- Enhanced RP discovery designed for rich clients (i.e. browser extensions) and the ability for RPs to specify information about themselves such as name, logo, etc for OPs to use (see "/site-meta" work).
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.
- Living document of security best practices.
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@yahoo-inc.com, Yahoo!
- Brad Fitzpatrick, brad@danga.com, Google
- Breno de Medeiros, breno@google.com, Google
- Carl Howells, chowells@janrain.com, JanRain
- Chris Messina, chris@citizenagency.com, Diso Project
- David Recordon, drecordon@sixapart.com, Six Apart
- Drummond Reed, drummond.reed@parityinc.net, Parity/Cordance/OASIS
- Gabe Wachob, gabe@wachob.com
- Gary Krall, gkrall@verisign.com, VeriSign
- John Bradley, jbradley@mac.com
- Johnny Bufu, johnny.bufu@gmail.com
- Joseph Smarr, jsmarr@plaxo.com, Plaxo
- Josh Hoyt, josh@janrain.com, JanRain
- Mart Atkins, matkins@sixapart.com, Six Apart
- Max Engel, mengel@myspace.com, MySpace
- Michael Richardson, michael@gobyairship.com
- Nat Sakimura, n-sakimura@nri.co.jp, NRI
- Scott Kveton, kveton@vidoop.com
- Will Norris, will@willnorris.com, Diso Project
- David Fuelling, sappenin@gmail.com, Sappenin Technologies
Initial Editors
- David Recordon, drecordon@sixapart.com, Six Apart
- John Bradley, jbradley@mac.com
- Allen Tom, atom@yahoo-inc.com, Yahoo! (focusing on the security best practices document)
- Chris Messina, chris@citizenagency.com, Diso Project