Proposing an OpenID Authentication 2.1 Working Group

Martin Atkins mart at
Sun Nov 9 23:19:15 UTC 2008

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 ( 
> ).
> 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 ( are evolving  
> the Yadis discovery protocol.
>   - EAUT ( 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 (, 
> ,,
> In addition, since the release of OpenID 2.0, OAuth (http:// 
> 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 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 
> . This is similar to a proposal made by Brad Fitzpatrick ( 
> ) 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!
>   - Brad Fitzpatrick, brad at, Google
>   - Breno de Medeiros, breno at, Google
>   - Carl Howells, chowells at, JanRain
>   - David Recordon, drecordon at, Six Apart
>   - Drummond Reed, drummond.reed at, Parity/Cordance/OASIS
>   - Gabe Wachob, gabe at
>   - Gary Krall, gkrall at, VeriSign
>   - John Bradley, jbradley at
>   - Johnny Bufu, johnny.bufu at
>   - Joseph Smarr, jsmarr at, Plaxo
>   - Josh Hoyt, josh at, JanRain
>   - Mart Atkins, matkins at, Six Apart
>   - Max Engel, mengel at, MySpace
>   - Scott Kveton, kveton at, Vidoop
> Initial Editors:
>   - David Recordon, drecordon at, Six Apart
>   - John Bradley, jbradley at
> _______________________________________________
> specs mailing list
> specs at

More information about the specs mailing list