If it indeed brings clarity to the situation, I'm not opposed, though one reason for using the "Connect" moniker is that "hybrid" means nothing outside of the OpenID community (since Hybrid really means combining authn and authz in a single protocol -- only relevant if your authn isn't tied to your authz in the first place!).

So, internally and for the WG name, I'm fine with going with OpenID Hybrid 2.0 WG -- but from an external marketing perspective I'd still prefer to have a *product* called OpenID Connect which would essentially be the hybrid 2.0 technology -- with additional guidance (perhaps) for optimizing UI flows. Thus to implement OpenID Connect would be to implement the hybrid 2.0 protocol with a series of contextually-optimized user interfaces -- with a cherry on top that looks like a "Connect" button.

Chris

Sent from my iPhone 2G

On May 25, 2010, at 2:56 PM, Allen Tom <a...@yahoo-inc.com> wrote:

Hi All,

A better way to look at OpenID Connect is to just think of it as revised version of the OpenID Hybrid. The purpose of the Hybrid WG was to find a way to combine OpenID Authentication with the approval of an Oauth access token
into a single request/response.

There are a several ways that OpenID Authentication can be combined with
Oauth - the current draft of the Hybrid spec defines one possible
implementation, however, based on the experience that we've had actually
implementing Hybrid, perhaps we can go about doing it differently.

Renaming the OpenID Connect WG to be the OpenID Hybrid v2 WG could possibly clarify the goals of the WG, and reduce confusion within the community. Afterall - Hybrid is intended for the case where the user's IdP is also the SP, so the Connect proposal is really a revised Hybrid proposal, rather than
a proposal for OpenID v.Next

Thoughts?
Allen



On 5/21/10 4:01 PM, "David Recordon" <record...@gmail.com> 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 - davidrecor...@facebook.com (editor)
Allen Tom - a...@yahoo-inc.com
Chuck Mortimore - cmortim...@salesforce.com
Chris Messina - mess...@google.com
Eran Hammer-Lahav - bl...@yahoo-inc.com
Joseph Smarr - jsm...@google.com
Luke Shepard - lshep...@facebook.com
Martin Atkins - matk...@sixapart.com
Max Engel - m...@gravity.com
Thomas Huhn - thomas.h...@gmail.com

3) Anticipated contributions: OpenID Connect proposal
(http://openidconnect.com) under the OpenID Foundation's IPR Policy.

_______________________________________________
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Reply via email to