+1 to Martin's idea.<br><br><div class="gmail_quote">On Sun, Nov 9, 2008 at 11:19 PM, Martin Atkins <span dir="ltr"><<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I'm in favor of working on a new version of OpenID Authentication with<br>
new features, but I think it's also important not to forget about 2.0. I<br>
think we should also publish a minor revision to 2.0 which includes only<br>
the errata and clarifications, not the new features. I'd like to have a<br>
spec to point to that describes today's implementations (bugs<br>
notwithstanding) to help with interop while we're working on the next<br>
big thing.<br>
<br>
As an analogy, consider that OpenID Authentication 2.1 is like CSS3 --<br>
it clarifies CSS 2.0, but it also adds new features that mean that it<br>
takes a long time to get published. CSS 2.1 was published in the interim<br>
with the express purpose of describing today's CSS implementations.<br>
<br>
This interim spec could either be an additional item published by the<br>
2.1 working group or a separate working group in its own right. The<br>
former will probably be easier, just so that the two groups don't end up<br>
duplicating work.<br>
<br>
I'd be great if this interim spec -- let's call it 2.0.1 -- would<br>
require little or no changes to present implementations. It would just<br>
be clarifying the corner cases that cause us interop problems today. It<br>
would therefore hopefully be non-controversial and should be turned<br>
around pretty quickly in comparison to the full 2.1 specification.<br>
<br>
Given that the additional items in David's proposal -- email addresses<br>
as identifiers and a new signature scheme -- are largely self-contained<br>
changes, it ought to be possible to work on them as standalone items<br>
while 2.0.1 is being written and then merge them to form 2.1 when the<br>
time comes.<br>
<div><div></div><div class="Wj3C7c"><br>
David Recordon wrote:<br>
> OpenID Authentication 2.0 was finalized this past December and since<br>
> has started to see quite reasonable adoption. Most libraries have<br>
> been updated to support 2.0 and most OpenID Providers support it as<br>
> well (in fact a few such as Google and Yahoo! only support 2.0).<br>
> Since the finalization of Authentication 2.0, numerous errata items<br>
> have been brought up via the OpenID mailing lists (some have already<br>
> been patched in SVN though not released). The community has also<br>
> gained clarity around security needs, current features usage, and<br>
> challenges facing OpenID for more mainstream adoption.<br>
><br>
> This draft Working Group proposal is designed to produce the next<br>
> version of OpenID Authentication — dubbed 2.1 — while maintaining<br>
> backwards compatibility with OpenID Authentication 2.0 implementations<br>
> already in use. This proposal outline follows the requirements of the<br>
> OpenID IPR Process document (<a href="http://openid.net/ipr/OpenID_Process_Document_%28Final_Clean_20071221%29.pdf" target="_blank">http://openid.net/ipr/OpenID_Process_Document_%28Final_Clean_20071221%29.pdf</a><br>
> ).<br>
><br>
> My goal of sending this draft out is to collect feedback prior to and<br>
> at the Internet Identity Workshop this coming week so that we can<br>
> officially create the working group later in the week. So please,<br>
> take a read, keep in mind that we're not trying to change too much at<br>
> any one time, and let us know what you think.<br>
><br>
> Thanks,<br>
> --David<br>
><br>
> Background Information:<br>
> Most of the related work for moving OpenID infrastructure forward is<br>
> occurring outside of the immediate OpenID specifications community:<br>
> - Projects like XRDS-Simple (<a href="http://xrds-simple.net/" target="_blank">http://xrds-simple.net/</a>) are evolving<br>
> the Yadis discovery protocol.<br>
> - EAUT (<a href="http://eaut.org/" target="_blank">http://eaut.org/</a>) among others are looking at email address-<br>
> style identifiers.<br>
> - The OpenID Foundation is investigating security considerations and<br>
> improvements.<br>
> - Various groups are working on projects that start to integrate<br>
> OpenID with the browser (<a href="http://www.sxipper.com/" target="_blank">http://www.sxipper.com/</a>, <a href="https://pip.verisignlabs.com/seatbelt.do" target="_blank">https://pip.verisignlabs.com/seatbelt.do</a><br>
> , <a href="http://blog.vidoop.com/archives/163" target="_blank">http://blog.vidoop.com/archives/163</a>, <a href="http://www.eclipse.org/higgins/" target="_blank">http://www.eclipse.org/higgins/</a>).<br>
> In addition, since the release of OpenID 2.0, OAuth (http://<br>
> <a href="http://oauth.net/" target="_blank">oauth.net/</a>) is now a finalized specification that is gaining adoption<br>
> and has a workflow similar to OpenID Authentication.<br>
><br>
> Working Group Name:<br>
> OpenID Authentication 2.1<br>
><br>
> Purpose:<br>
> Correct errata and update the Authentication 2.0 specification based<br>
> upon feedback from public implementations while maintaining backwards<br>
> compatibility with OpenID Authentication 2.0 to the greatest degree<br>
> possible.<br>
><br>
> Scope:<br>
> The proposed work is as follows:<br>
> - Perform "bug fixes" of incorrect wording and cleanup wording, add<br>
> diagrams, and if necessary restructure portions of the specification<br>
> to increase the overall readability and uniformity of interpretation.<br>
> - Apply clear copyright licensing language to the specification in<br>
> addition to noting that is covered by the OpenID Foundation IPR Policy<br>
> Non-Assertion Agreements.<br>
> - Add a new Appendix containing security guidance for implementers.<br>
> While not intended to be an exhaustive best practices guide, this<br>
> would consolidate in one section the most important guidelines for<br>
> securely implementing OpenID, and would incorporate key lessons<br>
> learned from public implementations.<br>
> - Clarifying XRDS Based Discovery for URLs possibly by migrating to<br>
> using XRDS-Simple. Note that this requires finalization of XRDS-Simple<br>
> as well as maintaining compatibility with OpenID Authentication 2.0<br>
> implementations.<br>
> - Clarifying if support of XRI as an identifier type is optional or<br>
> required by Relying Parties and specifying how to use an XRI to take<br>
> full advantage of its usability, security, and privacy properties.<br>
> - Clarifying whether OPs that support associations over HTTPS are<br>
> required to also support associations using Diffie-Hellman encryption<br>
> over HTTPS connections.<br>
> - Exploratory work as defined below assuming the Working Group finds<br>
> it feasible to do so.<br>
><br>
> Exploratory Work:<br>
> The WG will consider the following topics on an exploratory basis to<br>
> include in the specification:<br>
> - Support for email addresses as OpenID identifiers. It's been<br>
> shown that identifiers in the form of <a href="mailto:david@example.com">david@example.com</a> are easier for<br>
> mainstream users to understand, although there are multiple different<br>
> ways to implement this functionality. This has come up many times in<br>
> the past; various technological proposals have been made; and there is<br>
> at least one concrete shipping prototype (EAUT which was based on work<br>
> initiated by David Fuelling <a href="http://www.sappenin.com/openid/ext/oet/openid-email-transform-extension-1_0.html" target="_blank">http://www.sappenin.com/openid/ext/oet/openid-email-transform-extension-1_0.html</a>)<br>
> . This is similar to a proposal made by Brad Fitzpatrick (<a href="http://brad.livejournal.com/2357444.html" target="_blank">http://brad.livejournal.com/2357444.html</a><br>
> ) that should be explored further with regard to viability of email<br>
> addresses as an identifier type in the OpenID Authentication<br>
> specification. Note that this option may be dependent on large email<br>
> providers showing interest in supporting this style of identifier.<br>
> - Increasing reuse between OpenID Authentication and OAuth Core.<br>
> Both OpenID Authentication and OAuth Core share a similar protocol<br>
> flow with similar HMAC style cryptographic signing. OAuth uses a<br>
> slightly different and newer signing mechanism. Changing this in<br>
> OpenID Authentication would break backwards compatibility, but the WG<br>
> should explore the difference(s) and consider adding support for<br>
> OAuth's mechanism alongside the current mechanism for forwards<br>
> compatability.<br>
><br>
> Anticipated Contributions:<br>
> Specification text from a variety of contributors to achieve the goals<br>
> listed in the above scope.<br>
><br>
> Proposed List of Specifications:<br>
> OpenID Authentication 2.1. Completion expected within the next six<br>
> months.<br>
><br>
> Anticipated audience or users of the work:<br>
> Implementers of OpenID Providers and Relying Parties.<br>
><br>
> Language in which the WG will conduct business:<br>
> English.<br>
><br>
> Method of work:<br>
> E-mail discussions on the working group mailing list, working group<br>
> conference calls, and possibly a face-to-face meeting at the Internet<br>
> Identity Workshop.<br>
><br>
> Basis for determining when the work of the WG is completed:<br>
> Proposed changes will be evaluated on the basis of whether they<br>
> increase or decrease consensus within the working group. The work<br>
> will be completed once it is apparent that maximal consensus on the<br>
> draft has been achieved, consistent with the purpose and scope.<br>
><br>
> Proposers:<br>
> - Allen Tom, <a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>, Yahoo!<br>
> - Brad Fitzpatrick, <a href="mailto:brad@danga.com">brad@danga.com</a>, Google<br>
> - Breno de Medeiros, <a href="mailto:breno@google.com">breno@google.com</a>, Google<br>
> - Carl Howells, <a href="mailto:chowells@janrain.com">chowells@janrain.com</a>, JanRain<br>
> - David Recordon, <a href="mailto:drecordon@sixapart.com">drecordon@sixapart.com</a>, Six Apart<br>
> - Drummond Reed, <a href="mailto:drummond.reed@parityinc.net">drummond.reed@parityinc.net</a>, Parity/Cordance/OASIS<br>
> - Gabe Wachob, <a href="mailto:gabe@wachob.com">gabe@wachob.com</a><br>
> - Gary Krall, <a href="mailto:gkrall@verisign.com">gkrall@verisign.com</a>, VeriSign<br>
> - John Bradley, <a href="mailto:jbradley@mac.com">jbradley@mac.com</a><br>
> - Johnny Bufu, <a href="mailto:johnny.bufu@gmail.com">johnny.bufu@gmail.com</a><br>
> - Joseph Smarr, <a href="mailto:jsmarr@plaxo.com">jsmarr@plaxo.com</a>, Plaxo<br>
> - Josh Hoyt, <a href="mailto:josh@janrain.com">josh@janrain.com</a>, JanRain<br>
> - Mart Atkins, <a href="mailto:matkins@sixapart.com">matkins@sixapart.com</a>, Six Apart<br>
> - Max Engel, <a href="mailto:mengel@myspace.com">mengel@myspace.com</a>, MySpace<br>
> - Scott Kveton, <a href="mailto:kveton@vidoop.com">kveton@vidoop.com</a>, Vidoop<br>
><br>
> Initial Editors:<br>
> - David Recordon, <a href="mailto:drecordon@sixapart.com">drecordon@sixapart.com</a>, Six Apart<br>
> - John Bradley, <a href="mailto:jbradley@mac.com">jbradley@mac.com</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> specs mailing list<br>
> <a href="mailto:specs@openid.net">specs@openid.net</a><br>
> <a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
<br>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@openid.net">specs@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
</div></div></blockquote></div><br>