AB/Connect Working Group - Charter
AB/Connect Working Group
OVERVIEW
AB/Connect Working Group
CHARTER
AB/Connect Working Group
SPECIFICATIONS
AB/Connect Working Group
REPOSITORY
OpenID Artifact Binding Working Group Charter
1) Working Group name
Artifact Binding Working Group (AB)
2) Purpose
Produce a binding of OpenID requests and response (assertion) that uses direct communication for main payload and indirect communication for a small reference data called Artifact to cope with long URL limits experienced by man
3) Scope
Create the Artifact Binding to support the identified needs. Currently identified:
- Cope with long url problem, especially for mobile browsers.
- Cope with the security problems of non-encrypted payload to go through the user agents which may act as a man-in-the-middle.
4) Proposed specifications
OpenID Artifact Binding 1.0
5) Anticipated audience or users
All those interested in using OpenID in mobile and other constrained browser and server elements.
6) Language
English.
7) Method of work
Mailing list discussion. Posting of intermediate drafts in the OpenID Wiki. Virtual conferencing on an ad-hoc basis.
8) Basis for determining when the work is completed
The Artifact Binding 1.0 spec made final.
Related works
- SAML Artifact Binding
- OAuth
- Wrap
- Contract Exchange
Proposers
- Breno de Medeiros, Google, Inc.
- Hideki Nara, Tact Communications
- Nat Sakimura, NAT Consulting (editor)
- John Bradley, Yubico
- Allen Tom, Yahoo!
- Will Norris
Anticipated contributions
Connect Work Group Charter
1) Working Group name
Connect
2) Purpose
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.
Related works
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.
Proposers
- David Recordon (editor)
- Allen Tom
- Chuck Mortimore
- Chris Messina
- Eran Hammer-Lahav
- Joseph Smarr
- Luke Shepard
- Martin Atkins
- Max Engel
- Thomas Huhn
Anticipated contributions
OpenID Connect proposal (http://openidconnect.com) under the OpenID Foundation’s IPR Policy.
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.
Draft: OpenID Artifact Binding 1.0 – Draft 01, http://www.sakimura.org/
FICAM OpenID Connect Profile, Draft
This Working Group will target producing use cases and requirements within 2 months of inception in order to guide its design effort, and will target 6-12 months overall to develop a V1.0 set of profiles and other auxiliary materials, facilitating the development of multiple independent draft implementations as appropriate during this time. The following are suggested initial milestones for consideration by the Working Group:
- GIS Sept 2015: Approval of WG creation
- TBD Event to announce Implementer’s drafts (NLT 12 months after formal kickoff of WG).
- Interop testing among multiple implementations (once Implementer’s Drafts are available)
- TBD Event to announce Final profiles (NLT 6-12 months after Implementer’s Drafts)