<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Per my reasons outlined below, I do not think the Connect Charter is appropriate for the OIDF.<div><br></div><div>With a narrowed scope and clearly language (which is likely what most people think it is) -- I would support this WG Charter.</div><div><br></div><div>-- Dick<br><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;">June 4, 2010 6:37:46 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;">Martin Atkins <<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</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-council@lists.openid.net">openid-specs-council@lists.openid.net</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: [OIDFSC] Specs council status and work - POSSIBLE CALL TODAY</b><br></span></div><br><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 2010-06-04, at 12:03 PM, Martin Atkins wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 06/04/2010 11:52 AM, Dick Hardt wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">I asked a number of questions about Connect that I have not yet seen<br></blockquote><blockquote type="cite">responses to. I think the issues need to be addressed or the proposal<br></blockquote><blockquote type="cite">withdrawn.<br></blockquote><blockquote type="cite"><br></blockquote><br>Does this mean you wish to reject the proposal on the grounds of reason (a) in the process document?:<br> "an incomplete Proposal (i.e., failure to comply with section 4.1)"<br><br>If so, it would be useful to know precisely which of the line items in section 4.1 you think are lacking so that the proposal can be revised effectively.<br><br>From some of your comments in the thread on the specs list, I guess you might instead be rejecting it on the grounds of reason (b):<br> "a determination that the proposal contravenes the OpenID community's purpose"<br><br>If that is the case, I would be interested to hear in what you believe the OpenID community's purpose to be in this context and how the Connect proposal deviates from it.<br><font class="Apple-style-span"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div>4.1 (a) and (b)</div><div><br></div><div>4.1(a) Incomplete: I emailed David asking for a number of clarifications on the scope and purpose. (I will forward that email to the list after I send this one for easy reference)</div><div><br></div><div>I have inserted other questions in the draft charter below.</div><div><br></div><div>4.1(b) The current mission of the OpenID Foundation as voted on two meetings ago was to solve the internet identity problem by building on top of OpenID technology. The stated purpose of Connect is "building on top of OAuth 2.0 ". While this may be the right thing to do, it contravenes the OIDF Foundation's stated mission.</div><div><br></div><div>Additionally, the Connect WG overlaps with the Discovery, Core and User Experience WGs. It is the purpose of the Foundation to bring the community together to solve the issues together. </div><div><br></div><div>There are a number of aspects to Connect that are unique. If the scope is tightened up, the purpose clear, and it is described how this WG works with the other WGs, then we can move forward with this charter. For example, rather than doing discovery in this WG, Connect should defer discovery to the Discovery WG.</div><div><br></div><div>As it is, this charter is vague, wide ranging and heavily overlaps other working groups.</div><div><br></div><div>-- Dick</div><div><br></div><div><br></div><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>What will the protocol do? Will it do everything that OpenID 2.0 does? Is is a replacement for OpenID 2.0?</div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>Is the WG going to explore OAuth 2.0 or build on top of it per the pupose?</div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>discovery of what? this is vague -- see explicit discovery capabilities in the Discovery WG. Why is this done in Connect and not just use the output of the Discovery WG?</div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>I don't know what this means specifically. Is that not what a browser does today? It looks at the website, discovers things and interacts with it.</div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>Why do you want to explore this?</div><div>What is the objective?</div><div>What is the JRD reference for?</div><br><blockquote type="cite"><div><blockquote type="cite">- Explore the optimal migration path for implementors of OpenID 2.0<br></blockquote></div></blockquote><div><br></div><div>Explore or develop? Why the "optimal" adjective? Would this be in a spec? Documented in anyway? Is this a recommendation?</div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>All extensions? This seems very broad. What would be the output?</div><br><blockquote type="cite"><div><blockquote type="cite">- Explore how the concept of delegation should evolve<br></blockquote></div></blockquote><div><br></div><div>delegation of what? what do you mean by evolve? where do you want it to do?</div><div><br></div><div>With all these explorations, this seems more like a research project than a standardization effort.</div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>which server? I think I know what you mean, but it is not clear.</div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div>user typing in where? discovery of what? <div>what are you trying to solve. This again seems prescriptive of how it will work rather than describing scope. Is it a goal? </div><div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>why is this here? Is this a goal?</div><br><blockquote type="cite"><div><blockquote type="cite">- Drastically reduce the complexity of discovery<br></blockquote></div></blockquote><div><br></div><div>sounds like a goal rather than scope. </div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>verification of what? sounds very prescriptive rather than part of scope</div><br><blockquote type="cite"><div><blockquote type="cite">- Support optional static verification of the token response via a<br></blockquote><blockquote type="cite">signature using symmetric keys<br></blockquote></div></blockquote><div><br></div><div>which verification? which token?</div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>How does this relate to the User Experience WG?</div><br><blockquote type="cite"><div><blockquote type="cite">- Support the ability to login to non-web browser applications such<br></blockquote><blockquote type="cite">as desktop applications<br></blockquote></div></blockquote><div><br></div><div>login is vague -- authenticate? Are there other examples? Would the spec cover how these applications interact with the user?</div><br><blockquote type="cite"><div><blockquote type="cite">- Support dynamic registration of clients<br></blockquote></div></blockquote><div><br></div><div>registration of what? what is a client in this context? </div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>Wow. You are going to decide what the basic set of attributes are that are needed by all servers? Pretty broad scope!</div><div><br></div><br><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>rephrase to explain what is in scope -- ie., ensure that asymmetric keys can be used in the protocol</div><div><br></div><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></div></div></div></blockquote></div><br></div></body></html>