Connect Work Group proposal

Sat May 22 01:06:00 UTC 2010

Hi Mike,
We were able to take advantage of time at IIW to help shape this proposal as well as conversations around the web based on the technical proposal I shared. There is plenty of technical work for this Work Group to take on!

It is a formal request to create a Work Group. The Foundation's IPR Process instructs you to send Charter proposals to this list for review by the Specifications Council.

Thanks,
--David

On May 21, 2010, at 5:47 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:

> Hi David,
> 
> It isn't clear (at least to me) whether your note below is intended as:
>  - a completed charter and formal request to create a working group based upon that charter (without any prior discussion of the charter on the specs list) or
>  - a draft charter being circulated to the specs list for comment and consensus building before making a formal proposal based on the resulting charter.
> 
> Could you clarify the intent of the note below?
> 
> 				Thanks,
> 		-- Mike (a specs council member :-) )
> 
> -----Original Message-----
> From: openid-specs-bounces at lists.openid.net [mailto:openid-specs-bounces at lists.openid.net] On Behalf Of David Recordon
> Sent: Friday, May 21, 2010 4:02 PM
> To: openid-specs at lists.openid.net
> Cc: Chris Messina; Joseph Smarr; Martin Atkins; Max Engel; Luke Shepard; Eran Hammer-Lahav; Thomas Huhn
> Subject: Connect Work Group proposal
> 
> 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
> 