<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Martin<div><br></div><div>Below is the email that I sent out when I reviewed the Connect proposal. I have not seen any response to my questions.</div><div><br></div><div>-- Dick</div><div><br></div><div><br></div><div><br></div><div><blockquote type="cite"><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 48px; font: normal normal normal 13px/normal Arial; "><b>WG name:</b> User Experience.</p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 48px; font: normal normal normal 13px/normal Arial; "><b>(ii)</b> <b>Purpose:</b> Produce a user experience specification or family of specifications for OpenID 2.x that address the limitations and drawbacks present in the OpenID 2.0 that limit OpenID’s applicability, adoption, usability, privacy, and security. Specific goals are:</p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 60px; font: normal normal normal 13px/normal Arial; "><span style="font: normal normal normal 13px/normal 'Lucida Grande'; ">·</span><span style="font: normal normal normal 9px/normal 'Times New Roman'; "> </span>produce user experience guidelines for less intrusive authentication user experiences than full-page browser redirect,</p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 60px; font: normal normal normal 13px/normal Arial; "><span style="font: normal normal normal 13px/normal 'Lucida Grande'; ">·</span><span style="font: normal normal normal 9px/normal 'Times New Roman'; "> </span>produce user experience guidelines for controlled and uncontrolled release of attributes,</p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 60px; font: normal normal normal 13px/normal Arial; "><span style="font: normal normal normal 13px/normal 'Lucida Grande'; ">·</span><span style="font: normal normal normal 9px/normal 'Times New Roman'; "> </span>produce user experience guidelines for use of identities and attributes by non-browser applications,</p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 60px; font: normal normal normal 13px/normal Arial; "><span style="font: normal normal normal 13px/normal 'Lucida Grande'; ">·</span><span style="font: normal normal normal 9px/normal 'Times New Roman'; "> </span>produce user experience guidelines for optimized protocol flows combining authentication, attribute release, and resource authorization,</p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 60px; font: normal normal normal 13px/normal Arial; "><span style="font: normal normal normal 13px/normal 'Lucida Grande'; ">·</span><span style="font: normal normal normal 9px/normal 'Times New Roman'; "> </span>produce user experience guidelines for use of OpenID on mobile devices,</p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 60px; font: normal normal normal 13px/normal Arial; "><span style="font: normal normal normal 13px/normal 'Lucida Grande'; ">·</span><span style="font: normal normal normal 9px/normal 'Times New Roman'; "> </span>seamlessly integrate with and complement the other OpenID 2.x specifications.</p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 48px; font: normal normal normal 13px/normal Arial; min-height: 15px; "><br></p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 48px; font: normal normal normal 13px/normal Arial; ">Compatibility with OpenID 2.x is an explicit goal for this work.</p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 48px; font: normal normal normal 13px/normal Arial; min-height: 15px; "><b></b><br></p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 2px; margin-left: 48px; font: normal normal normal 13px/normal Arial; "><b>(iii)</b> <b>Scope:</b> Produce a current generation OpenID user experience specification or specifications, consistent with the purpose statement.</p></blockquote></div><div><br></div><div><br></div><div><br></div><div><blockquote type="cite"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt; "><b>(i)</b> <b>WG name:</b> v.Next Discovery.<br><b>(ii)</b> <b>Purpose:</b> Produce a discovery specification or family of discovery specifications for OpenID v.Next that address the limitations and drawbacks present in the OpenID 2.0 discovery facilities that limit OpenID’s applicability, adoption, usability, privacy, and security. Specific goals are:<br></span></font><span style="font-size: 11pt; "><font face="Symbol">· </font><font face="Times New Roman"> </font><font face="Calibri, Verdana, Helvetica, Arial">enable discovery for and normalization of OpenID identifiers, including those utilizing e-mail address syntax and those that are URLs,<br><br></font><font face="Symbol">· </font><font face="Times New Roman"> </font><font face="Calibri, Verdana, Helvetica, Arial">enable discovery of features supported by OpenID v.Next OpenID Providers and Relying Parties,<br><br></font><font face="Symbol">· </font><font face="Times New Roman"> </font><font face="Calibri, Verdana, Helvetica, Arial">enable discovery of attributes about OpenID v.Next OPs and RPs, including, but not limited to visual logos and human-readable site names,<br><br></font><font face="Symbol">· </font><font face="Times New Roman"> </font><font face="Calibri, Verdana, Helvetica, Arial">enable discovery supporting a spectrum of clients, including passive clients per current usage, thin active clients, and active clients with OP functionality,<br><br></font><font face="Symbol">· </font><font face="Times New Roman"> </font><font face="Calibri, Verdana, Helvetica, Arial">enable discovery supporting authentication to and use of attributes by non-browser applications,<br><br></font><font face="Symbol">· </font><font face="Times New Roman"> </font><font face="Calibri, Verdana, Helvetica, Arial">enable discovery of public keys,<br><br></font><font face="Symbol">· </font><font face="Times New Roman"> </font><font face="Calibri, Verdana, Helvetica, Arial">enable potential mechanisms for discovering context-relevant OpenID providers,<br><br></font><font face="Symbol">· </font><font face="Times New Roman"> </font><font face="Calibri, Verdana, Helvetica, Arial">seamlessly integrate with and complement the other OpenID v.Next specifications.<br><br> Compatibility with OpenID 2.0 is an explicit non-goal for this work.<br><b>(iii)</b> <b>Scope:</b> Produce a next generation OpenID discovery specification or specifications, consistent with the purpose statement.</font></span></blockquote><div><br></div><div><br></div><div><br></div><div><blockquote type="cite">(i) <b>WG name:</b> Core Protocol.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(ii) <b>Purpose</b>: Produce a core protocol specification or<br></blockquote><blockquote type="cite">family of specifications for OpenID v.Next that address the limitations and<br></blockquote><blockquote type="cite">drawbacks present in OpenID 2.0 that limit OpenID’s applicability, adoption,<br></blockquote><blockquote type="cite">usability, privacy, and security. Specific goals are:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· define core message flows and verification methods,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· enable support for controlled release of attributes,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· enable aggregation of attributes from multiple attribute sources,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· enable attribute sources to provide verified attributes,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· enable the sources of attributes to be verified,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· enable support for a spectrum of clients, including passive clients<br></blockquote><blockquote type="cite">per current usage, thin active clients, and active clients with OP<br></blockquote><blockquote type="cite">functionality,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· enable authentication to and use of attributes by non-browser<br></blockquote><blockquote type="cite">applications,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· enable optimized protocol flows combining authentication, attribute<br></blockquote><blockquote type="cite">release, and resource authorization,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· define profiles and support features intended to enable OpenID to be<br></blockquote><blockquote type="cite">used at levels of assurance higher than NIST SP800-63 v2 level 1 ,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· ensure the use of OpenID on mobile and other emerging devices,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· ensure the use of OpenID on existing browsers with URL length<br></blockquote><blockquote type="cite">restrictions,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· define an extension mechanism for identified capabilities that are<br></blockquote><blockquote type="cite">not in the core specification<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> · evaluate the use of public key technology to enhance, security,<br></blockquote><blockquote type="cite">scalability and performance,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· evaluate inclusion of single sign out<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· evaluate mechanisms for providing redundancy<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· complement OAuth 2.0<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· minimize migration effort from OpenID 2.0<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· seamlessly integrate with and complement the other OpenID v.Next<br></blockquote><blockquote type="cite">specifications.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">· depreciate redundant or unused mechanisms<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> Compatibility with OpenID 2.0 is an explicit non-goal for this work.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(iii) Scope: Produce a next generation OpenID core<br></blockquote><blockquote type="cite">protocol specification or specifications, consistent with the purpose<br></blockquote><blockquote type="cite">statement.<br></blockquote><div><br></div></div><div><br></div><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Dick Hardt <<a href="mailto:dick.hardt@gmail.com">dick.hardt@gmail.com</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">May 21, 2010 4:47:28 PM PDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">David Recordon <<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Cc: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><a href="mailto:openid-specs@lists.openid.net">openid-specs@lists.openid.net</a>, Chris Messina <<a href="mailto:messina@google.com">messina@google.com</a>>, Joseph Smarr <<a href="mailto:jsmarr@google.com">jsmarr@google.com</a>>, Martin Atkins <<a href="mailto:matkins@sixapart.com">matkins@sixapart.com</a>>, Max Engel <<a href="mailto:max@gravity.com">max@gravity.com</a>>, Luke Shepard <<a href="mailto:lshepard@facebook.com">lshepard@facebook.com</a>>, Eran Hammer-Lahav <<a href="mailto:blade@yahoo-inc.com">blade@yahoo-inc.com</a>>, Thomas Huhn <<a href="mailto:thomas.huhn@gmail.com">thomas.huhn@gmail.com</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Re: Connect Work Group proposal</b><br></span></div><br><div>Hi David<br><br>A couple initial comments:<br><br>1) Please explain what problem(s) you are trying to solve. You list a number of explorations and goals and there are some implicit requirements. It would be useful to explicitly state the requirements so that everyone can understand why this work is important to do. It is unclear how this complements other OIDF WGs per the stated purpose.<br><br>2) What is different from the v.Next efforts? If this is a different approach to the same problem, it would seem to make sense to argue the different technical merits in one WG rather then two. Why is this WG is needed in addition to the v.Next work that is starting to spin up? Many members of the community gathered at the OpenID Summit, (a meeting you helped organize David!) and the consensus was the v.Next WGs that were kicked off. If you are unhappy with the progress there, how about putting effort into moving those along rather than starting a new WG?<br><br>I have numerous other comments on the Scope section, but would like to deal with the two issues above first.<br><br>-- Dick<br><br>On 2010-05-21, at 4:01 PM, David Recordon wrote:<br><br><blockquote type="cite">Per the OpenID Foundation's IPR Process, below is a Work Group Charter<br></blockquote><blockquote type="cite">proposal for consideration by the Specifications Council.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thanks,<br></blockquote><blockquote type="cite">--David<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Charter:<br></blockquote><blockquote type="cite">1) Working Group name: Connect<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">2) Purpose: Develop a version of the OpenID protocol optimized for use<br></blockquote><blockquote type="cite">on the web by building on top of OAuth 2.0 and discovery technologies<br></blockquote><blockquote type="cite">such as host-meta while complementing other active OpenID Foundation<br></blockquote><blockquote type="cite">Working Groups.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">3) Scope:<br></blockquote><blockquote type="cite">- Explore building on top of OAuth 2.0<br></blockquote><blockquote type="cite">(<a href="http://wiki.oauth.net/OAuth-2.0">http://wiki.oauth.net/OAuth-2.0</a>) from the IETF for the user<br></blockquote><blockquote type="cite">authorization flows and extension mechanism<br></blockquote><blockquote type="cite">- Explore using the Web Host Metadata specification<br></blockquote><blockquote type="cite">(<a href="http://tools.ietf.org/html/draft-hammer-hostmeta">http://tools.ietf.org/html/draft-hammer-hostmeta</a>) and Well Known URIs<br></blockquote><blockquote type="cite">(<a href="http://tools.ietf.org/html/rfc5785">http://tools.ietf.org/html/rfc5785</a>) via SSL for discovery<br></blockquote><blockquote type="cite">- Explore the ability for a rich client (such as a browser) to<br></blockquote><blockquote type="cite">discover and interact with the website on the user's behalf<br></blockquote><blockquote type="cite">- Explore making user identifiers OAuth 2.0 protected resources which<br></blockquote><blockquote type="cite">return profile information and links to other API endpoints possibly<br></blockquote><blockquote type="cite">using JRD (<a href="http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/">http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/</a>)<br></blockquote><blockquote type="cite">assuming it is submitted to the IETF<br></blockquote><blockquote type="cite">- Explore the optimal migration path for implementors of OpenID 2.0<br></blockquote><blockquote type="cite">- Explore how the functionality provided by existing OpenID 2.0<br></blockquote><blockquote type="cite">extensions could be re-imagined on top of OpenID Connect<br></blockquote><blockquote type="cite">- Explore how the concept of delegation should evolve<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">- Support for simultaneously authenticating the user while also<br></blockquote><blockquote type="cite">authorizing other OAuth 2.0 protected resources that the server is<br></blockquote><blockquote type="cite">able to issue access tokens for<br></blockquote><blockquote type="cite">- Support users explicitly choosing a server or typing in a variety<br></blockquote><blockquote type="cite">of URLs and email addresses for discovery<br></blockquote><blockquote type="cite">- Separate the user identifier from the user's human consumable<br></blockquote><blockquote type="cite">profile URL such that it is hosted via HTTPS, globally unique, and<br></blockquote><blockquote type="cite">never reassigned<br></blockquote><blockquote type="cite">- Drastically reduce the complexity of discovery<br></blockquote><blockquote type="cite">- Reduce the complexity of the verification processes possibly by<br></blockquote><blockquote type="cite">comparing the subdomain of the user identifier and token endpoint<br></blockquote><blockquote type="cite">- Support optional static verification of the token response via a<br></blockquote><blockquote type="cite">signature using symmetric keys<br></blockquote><blockquote type="cite">- Support user interfaces optimized for a variety of screen sizes,<br></blockquote><blockquote type="cite">devices, and languages by learning from the OpenID User Experience<br></blockquote><blockquote type="cite">extension<br></blockquote><blockquote type="cite">- Support the ability to login to non-web browser applications such<br></blockquote><blockquote type="cite">as desktop applications<br></blockquote><blockquote type="cite">- Support dynamic registration of clients<br></blockquote><blockquote type="cite">- Define a standard mechanism and basic set of attributes for servers<br></blockquote><blockquote type="cite">to share basic user profile data with clients<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">- Do not prevent the use of asymmetric keys throughout the protocol<br></blockquote><blockquote type="cite">such that it may scale into more security conscious use cases<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">4) Proposed specifications: OpenID Connect 1.0.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">5) Anticipated audience or users: Implementors of OpenID providers,<br></blockquote><blockquote type="cite">relying parties, web browsers, and other non-browser applications.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">6) Language: English<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">7) Method of work: E-mail discussions on the working group mailing<br></blockquote><blockquote type="cite">list, working group conference calls, and face-to-face meetings at the<br></blockquote><blockquote type="cite">Internet Identity Workshop and OpenID Foundation hosted summits.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">8) Basis for determining when the work is completed: Rough consensus<br></blockquote><blockquote type="cite">and running code. The work will be completed once it is apparent that<br></blockquote><blockquote type="cite">maximal consensus on the draft has been achieved, consistent with the<br></blockquote><blockquote type="cite">purpose and scope.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Background information:<br></blockquote><blockquote type="cite">1) Related work: OpenID Authentication 2.0 and related specifications,<br></blockquote><blockquote type="cite">including Attribute Exchange (AX), Contract Exchange (CX), Provider<br></blockquote><blockquote type="cite">Authentication Policy Extension (PAPE), and the draft User Interface<br></blockquote><blockquote type="cite">(UI) Extension. OAuth 2.0. Web Host Metadata, Well Known URIs, LRDD,<br></blockquote><blockquote type="cite">XRD, and JRD. OpenID v.Next Working Group proposals. Mozilla Account<br></blockquote><blockquote type="cite">Manager. Google "EasyHybrid". The Connect Working Group is needed to<br></blockquote><blockquote type="cite">explore how many of these related technologies can be used to build an<br></blockquote><blockquote type="cite">open identity system for the web while remaining consistant with the<br></blockquote><blockquote type="cite">principals behind OpenID 1.0 and OpenID 2.0. The Proposers have strong<br></blockquote><blockquote type="cite">relationships in many of these communities and do not anticipate the<br></blockquote><blockquote type="cite">need of formal liaisons.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">2) Proposers:<br></blockquote><blockquote type="cite">David Recordon - <a href="mailto:davidrecordon@facebook.com">davidrecordon@facebook.com</a> (editor)<br></blockquote><blockquote type="cite">Allen Tom - <a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a><br></blockquote><blockquote type="cite">Chuck Mortimore - <a href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a><br></blockquote><blockquote type="cite">Chris Messina - <a href="mailto:messina@google.com">messina@google.com</a><br></blockquote><blockquote type="cite">Eran Hammer-Lahav - <a href="mailto:blade@yahoo-inc.com">blade@yahoo-inc.com</a><br></blockquote><blockquote type="cite">Joseph Smarr - <a href="mailto:jsmarr@google.com">jsmarr@google.com</a><br></blockquote><blockquote type="cite">Luke Shepard - <a href="mailto:lshepard@facebook.com">lshepard@facebook.com</a><br></blockquote><blockquote type="cite">Martin Atkins - <a href="mailto:matkins@sixapart.com">matkins@sixapart.com</a><br></blockquote><blockquote type="cite">Max Engel - <a href="mailto:max@gravity.com">max@gravity.com</a><br></blockquote><blockquote type="cite">Thomas Huhn - <a href="mailto:thomas.huhn@gmail.com">thomas.huhn@gmail.com</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">3) Anticipated contributions: OpenID Connect proposal<br></blockquote><blockquote type="cite">(<a href="http://openidconnect.com">http://openidconnect.com</a>) under the OpenID Foundation's IPR Policy.<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">specs mailing list<br></blockquote><blockquote type="cite"><a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br></blockquote><blockquote type="cite"><a href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a><br></blockquote><br></div></blockquote></div><br></div></body></html>