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 TrackingTo 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
<Component> values in the issue tracker are currently:
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.)
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
When making a commit, use the following syntax for the commit messages so that the issues are linked to the commit.
<command> <issue id>
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
<issue id> SHOULD be specified as