[OIDFSC] Fwd: Connect Work Group proposal
Dick Hardt
dick.hardt at gmail.com
Sat Jun 5 01:37:45 UTC 2010
Hi Martin
Below is the email that I sent out when I reviewed the Connect proposal. I have not seen any response to my questions.
-- Dick
> 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.
Begin forwarded message:
> From: Dick Hardt <dick.hardt at gmail.com>
> Date: May 21, 2010 4:47:28 PM PDT
> To: David Recordon <recordond at gmail.com>
> Cc: openid-specs at lists.openid.net, Chris Messina <messina at google.com>, Joseph Smarr <jsmarr at google.com>, Martin Atkins <matkins at sixapart.com>, Max Engel <max at gravity.com>, Luke Shepard <lshepard at facebook.com>, Eran Hammer-Lahav <blade at yahoo-inc.com>, Thomas Huhn <thomas.huhn at gmail.com>
> Subject: Re: Connect Work Group proposal
>
> Hi David
>
> A couple initial comments:
>
> 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.
>
> 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?
>
> I have numerous other comments on the Scope section, but would like to deal with the two issues above first.
>
> -- Dick
>
> On 2010-05-21, at 4:01 PM, David Recordon wrote:
>
>> Per the OpenID Foundation's IPR Process, below is a Work Group Charter
>> proposal for consideration by the Specifications Council.
>>
>> Thanks,
>> --David
>>
>>
>> Charter:
>> 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.
>>
>> 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
>> - 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
>> - Explore the ability for a rich client (such as a browser) to
>> discover and interact with the website on the user's behalf
>> - 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
>> - Explore the optimal migration path for implementors of OpenID 2.0
>> - Explore how the functionality provided by existing OpenID 2.0
>> extensions could be re-imagined on top of OpenID Connect
>> - Explore how the concept of delegation should evolve
>>
>> - 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
>> - Support users explicitly choosing a server or typing in a variety
>> of URLs and email addresses for discovery
>> - Separate the user identifier from the user's human consumable
>> profile URL such that it is hosted via HTTPS, globally unique, and
>> never reassigned
>> - Drastically reduce the complexity of discovery
>> - Reduce the complexity of the verification processes possibly by
>> comparing the subdomain of the user identifier and token endpoint
>> - Support optional static verification of the token response via a
>> signature using symmetric keys
>> - Support user interfaces optimized for a variety of screen sizes,
>> devices, and languages by learning from the OpenID User Experience
>> extension
>> - Support the ability to login to non-web browser applications such
>> as desktop applications
>> - Support dynamic registration of clients
>> - Define a standard mechanism and basic set of attributes for servers
>> to share basic user profile data with clients
>>
>> - Do not prevent the use of asymmetric keys throughout the protocol
>> such that it may scale into more security conscious use cases
>>
>> 4) Proposed specifications: OpenID Connect 1.0.
>>
>> 5) Anticipated audience or users: Implementors of OpenID providers,
>> relying parties, web browsers, and other non-browser applications.
>>
>> 6) Language: English
>>
>> 7) Method of work: E-mail discussions on the working group mailing
>> list, working group conference calls, and face-to-face meetings at the
>> Internet Identity Workshop and OpenID Foundation hosted summits.
>>
>> 8) Basis for determining when the work is completed: Rough consensus
>> and running code. The work will be completed once it is apparent that
>> maximal consensus on the draft has been achieved, consistent with the
>> purpose and scope.
>>
>>
>> Background information:
>> 1) Related work: OpenID Authentication 2.0 and related specifications,
>> including Attribute Exchange (AX), Contract Exchange (CX), Provider
>> Authentication Policy Extension (PAPE), and the draft User Interface
>> (UI) Extension. OAuth 2.0. Web Host Metadata, Well Known URIs, LRDD,
>> XRD, and JRD. OpenID v.Next Working Group proposals. Mozilla Account
>> Manager. Google "EasyHybrid". The Connect Working Group is needed to
>> explore how many of these related technologies can be used to build an
>> open identity system for the web while remaining consistant with the
>> principals behind OpenID 1.0 and OpenID 2.0. The Proposers have strong
>> relationships in many of these communities and do not anticipate the
>> need of formal liaisons.
>>
>> 2) Proposers:
>> David Recordon - davidrecordon at facebook.com (editor)
>> Allen Tom - atom at yahoo-inc.com
>> Chuck Mortimore - cmortimore at salesforce.com
>> Chris Messina - messina at google.com
>> Eran Hammer-Lahav - blade at yahoo-inc.com
>> Joseph Smarr - jsmarr at google.com
>> Luke Shepard - lshepard at facebook.com
>> Martin Atkins - matkins at sixapart.com
>> Max Engel - max at gravity.com
>> Thomas Huhn - thomas.huhn at gmail.com
>>
>> 3) Anticipated contributions: OpenID Connect proposal
>> (http://openidconnect.com) under the OpenID Foundation's IPR Policy.
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20100604/09f41a8b/attachment-0001.html>
More information about the specs-council
mailing list