OpenID Connect Editor's Drafts

Below are links to the HTML versions of the editor's drafts of the specifications and implementer's guides:

Editor's Drafts of Errata Updates to Final Specifications

Core - Defines the core OpenID Connect functionality: authentication built on top of OAuth 2.0 and the use of Claims to communicate information about the End-User
Discovery - (Optional) Defines how RPs dynamically discover information about OpenID Providers
Dynamic Registration - (Optional) Defines how RPs dynamically register with OpenID Providers

Editor's Drafts of Specifications with Implementer's Draft Status

Session Management - (Optional) Defines how to manage OpenID Connect sessions, including postMessage-based logout functionality
Front-Channel Logout - (Optional) Defines a front-channel logout mechanism that does not use an OP iframe on RP pages
Back-Channel Logout - (Optional) Defines a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out
OpenID Connect Federation - (Optional) Defines how sets of OPs and RPs can establish trust by utilizing a Federation Operator

Editor's Drafts of Final Specifications without Errata Updates

OAuth 2.0 Multiple Response Types - Defines several specific new OAuth 2.0 response types
OAuth 2.0 Form Post Response Mode - (Optional) Defines how to return OAuth 2.0 Authorization Response parameters (including OpenID Connect Authentication Response parameters) using HTML form values that are auto-submitted by the User Agent using HTTP POST
OpenID 2.0 to OpenID Connect Migration - (Optional) Defines how to migrate from OpenID 2.0 to OpenID Connect

Editor's Drafts of Other Specifications

OpenID Connect Profile for SCIM Services - (Optional) Defines how to use SCIM with OpenID Connect

Editor's Drafts of Implementer's Guides

Basic Client Implementer's Guide - (Implementer's Guide) Simple subset of the Core functionality for a web-based Relying Party using the OAuth code flow
Implicit Client Implementer's Guide - (Implementer's Guide) Simple subset of the Core functionality for a web-based Relying Party using the OAuth implicit flow

Issue Tracking

To submit an issue to the specifications, use the following syntax in the issue title:


<SpecAbbrev> - <Section.Number> <Descritpion>.

For example, to submit a comment on section 4.3.2 of the Core spec, write the title as


Core - 4.3.2 This is the title for the issue

The <Component> values in the issue tracker are currently:

All
Core
Discovery
Registration
Session
Responses
FrontChannel
BackChannel
Basic
Implicit

Working with the Repository

This working repository uses Mercurial for the version control. The server uses bitbucket.

To work on the repository, you need to do the following:

As a preparation:

Fill in the Contribution Agreement so that you join "OpenID AB/Connect Working Group."
(If you have not already done so, install Mercurial.)

CUI: http://mercurial.selenic.com/
GUI: http://tortoisehg.org/

(If you do not already have, create Bitbucket userid).
Tell Nat/Mike/John the userid - they you will get a write previllege.

Then start working with the repository as:

Clone the repository. (The command to use is on https://bitbucket.org/openid/connect/src/default.)
hg pull
(edit a file)
hg commit -m 'fix #45 - typo'
hg push

Make sure that

You only do one edit per commit.
You include the <command> and <issue number> in the commit message. (See below.)

For more details, see: http://confluence.atlassian.com/display/BITBUCKET/Bitbucket+101

Commit Messages

When making a commit, use the following syntax for the commit messages so that the issues are linked to the commit.

<command> <issue id>

For example,


  Fix #45 - Typo fixed.

<command> can be one of the followings:


close/closed/closes/closing/fix/fixed/fixes    # resolves the issue
reopen/reopens/reopening                       # reopens the issue
addresses/re/references/ref/refs/see           # adds a link to the changeset as a comment for the issue

The <issue id> SHOULD be specified as #45 etc.