Per my reasons outlined below, I do not think the Connect Charter is appropriate for the OIDF.
With a narrowed scope and clearly language (which is likely what most people think it is) -- I would support this WG Charter. -- Dick Begin forwarded message: > From: Dick Hardt <[email protected]> > Date: June 4, 2010 6:37:46 PM PDT > To: Martin Atkins <[email protected]> > Cc: [email protected] > Subject: Re: [OIDFSC] Specs council status and work - POSSIBLE CALL TODAY > > > On 2010-06-04, at 12:03 PM, Martin Atkins wrote: > >> On 06/04/2010 11:52 AM, Dick Hardt wrote: >>> >>> I asked a number of questions about Connect that I have not yet seen >>> responses to. I think the issues need to be addressed or the proposal >>> withdrawn. >>> >> >> Does this mean you wish to reject the proposal on the grounds of reason (a) >> in the process document?: >> "an incomplete Proposal (i.e., failure to comply with section 4.1)" >> >> 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. >> >> 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): >> "a determination that the proposal contravenes the OpenID community's >> purpose" >> >> 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. >> > > 4.1 (a) and (b) > > 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) > > I have inserted other questions in the draft charter below. > > 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. > > 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. > > 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. > > As it is, this charter is vague, wide ranging and heavily overlaps other > working groups. > > -- Dick > > >>> 1) Working Group name: Connect >>> >>> 2) Purpose: Develop a version of the OpenID protocol optimized for use >>> on the web by building on top of OAuth 2.0 and discovery technologies >>> such as host-meta while complementing other active OpenID Foundation >>> Working Groups. > > What will the protocol do? Will it do everything that OpenID 2.0 does? Is is > a replacement for OpenID 2.0? > >>> >>> 3) Scope: >>> - Explore building on top of OAuth 2.0 >>> (http://wiki.oauth.net/OAuth-2.0) from the IETF for the user >>> authorization flows and extension mechanism > > Is the WG going to explore OAuth 2.0 or build on top of it per the pupose? > >>> - Explore using the Web Host Metadata specification >>> (http://tools.ietf.org/html/draft-hammer-hostmeta) and Well Known URIs >>> (http://tools.ietf.org/html/rfc5785) via SSL for discovery > > 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? > >>> - Explore the ability for a rich client (such as a browser) to >>> discover and interact with the website on the user's behalf > > 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. > >>> - Explore making user identifiers OAuth 2.0 protected resources which >>> return profile information and links to other API endpoints possibly >>> using JRD (http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/) >>> assuming it is submitted to the IETF > > Why do you want to explore this? > What is the objective? > What is the JRD reference for? > >>> - Explore the optimal migration path for implementors of OpenID 2.0 > > Explore or develop? Why the "optimal" adjective? Would this be in a spec? > Documented in anyway? Is this a recommendation? > >>> - Explore how the functionality provided by existing OpenID 2.0 >>> extensions could be re-imagined on top of OpenID Connect > > All extensions? This seems very broad. What would be the output? > >>> - Explore how the concept of delegation should evolve > > delegation of what? what do you mean by evolve? where do you want it to do? > > With all these explorations, this seems more like a research project than a > standardization effort. > >>> >>> - Support for simultaneously authenticating the user while also >>> authorizing other OAuth 2.0 protected resources that the server is >>> able to issue access tokens for > > which server? I think I know what you mean, but it is not clear. > >>> - Support users explicitly choosing a server or typing in a variety >>> of URLs and email addresses for discovery > > user typing in where? discovery of what? > what are you trying to solve. This again seems prescriptive of how it will > work rather than describing scope. Is it a goal? > >>> - Separate the user identifier from the user's human consumable >>> profile URL such that it is hosted via HTTPS, globally unique, and >>> never reassigned > > why is this here? Is this a goal? > >>> - Drastically reduce the complexity of discovery > > sounds like a goal rather than scope. > >>> - Reduce the complexity of the verification processes possibly by >>> comparing the subdomain of the user identifier and token endpoint > > verification of what? sounds very prescriptive rather than part of scope > >>> - Support optional static verification of the token response via a >>> signature using symmetric keys > > which verification? which token? > >>> - Support user interfaces optimized for a variety of screen sizes, >>> devices, and languages by learning from the OpenID User Experience >>> extension > > How does this relate to the User Experience WG? > >>> - Support the ability to login to non-web browser applications such >>> as desktop applications > > login is vague -- authenticate? Are there other examples? Would the spec > cover how these applications interact with the user? > >>> - Support dynamic registration of clients > > registration of what? what is a client in this context? > >>> - Define a standard mechanism and basic set of attributes for servers >>> to share basic user profile data with clients > > Wow. You are going to decide what the basic set of attributes are that are > needed by all servers? Pretty broad scope! > > >>> >>> - Do not prevent the use of asymmetric keys throughout the protocol >>> such that it may scale into more security conscious use cases > > rephrase to explain what is in scope -- ie., ensure that asymmetric keys can > be used in the protocol > > >> WG name: User Experience. >> (ii) Purpose: 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: >> · produce user experience guidelines for less intrusive >> authentication user experiences than full-page browser redirect, >> · produce user experience guidelines for controlled and uncontrolled >> release of attributes, >> · produce user experience guidelines for use of identities and >> attributes by non-browser applications, >> · produce user experience guidelines for optimized protocol flows >> combining authentication, attribute release, and resource authorization, >> · produce user experience guidelines for use of OpenID on mobile >> devices, >> · seamlessly integrate with and complement the other OpenID 2.x >> specifications. >> >> Compatibility with OpenID 2.x is an explicit goal for this work. >> >> (iii) Scope: Produce a current generation OpenID user experience >> specification or specifications, consistent with the purpose statement. > > > > >> (i) WG name: v.Next Discovery. >> (ii) Purpose: 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: >> · enable discovery for and normalization of OpenID identifiers, >> including those utilizing e-mail address syntax and those that are URLs, >> >> · enable discovery of features supported by OpenID v.Next OpenID >> Providers and Relying Parties, >> >> · enable discovery of attributes about OpenID v.Next OPs and RPs, >> including, but not limited to visual logos and human-readable site names, >> >> · enable discovery supporting a spectrum of clients, including passive >> clients per current usage, thin active clients, and active clients with OP >> functionality, >> >> · enable discovery supporting authentication to and use of attributes by >> non-browser applications, >> >> · enable discovery of public keys, >> >> · enable potential mechanisms for discovering context-relevant OpenID >> providers, >> >> · seamlessly integrate with and complement the other OpenID v.Next >> specifications. >> >> Compatibility with OpenID 2.0 is an explicit non-goal for this >> work. >> (iii) Scope: Produce a next generation OpenID discovery specification or >> specifications, consistent with the purpose statement. > > > >> (i) WG name: Core Protocol. >> >> (ii) Purpose: Produce a core protocol specification or >> family of specifications for OpenID v.Next that address the limitations and >> drawbacks present in OpenID 2.0 that limit OpenID’s applicability, adoption, >> usability, privacy, and security. Specific goals are: >> >> · define core message flows and verification methods, >> >> · enable support for controlled release of attributes, >> >> · enable aggregation of attributes from multiple attribute sources, >> >> · enable attribute sources to provide verified attributes, >> >> · enable the sources of attributes to be verified, >> >> · enable support for a spectrum of clients, including passive clients >> per current usage, thin active clients, and active clients with OP >> functionality, >> >> · enable authentication to and use of attributes by non-browser >> applications, >> >> · enable optimized protocol flows combining authentication, attribute >> release, and resource authorization, >> >> · define profiles and support features intended to enable OpenID to be >> used at levels of assurance higher than NIST SP800-63 v2 level 1 , >> >> · ensure the use of OpenID on mobile and other emerging devices, >> >> · ensure the use of OpenID on existing browsers with URL length >> restrictions, >> >> · define an extension mechanism for identified capabilities that are >> not in the core specification >> >> · evaluate the use of public key technology to enhance, security, >> scalability and performance, >> >> · evaluate inclusion of single sign out >> >> · evaluate mechanisms for providing redundancy >> >> · complement OAuth 2.0 >> >> · minimize migration effort from OpenID 2.0 >> >> · seamlessly integrate with and complement the other OpenID v.Next >> specifications. >> >> · depreciate redundant or unused mechanisms >> >> Compatibility with OpenID 2.0 is an explicit non-goal for this work. >> >> (iii) Scope: Produce a next generation OpenID core >> protocol specification or specifications, consistent with the purpose >> statement. >
_______________________________________________ board mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-board
