OpenID Connect 1.0 Official Working Repository
List of Specifications
Below are links to the HTML versions of the working copies of the specifications and implementer's guides:
- 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
- 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
- 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
- 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
- OpenID 2.0 to OpenID Connect Migration - (Optional) Defines how to migrate from OpenID 2.0 to OpenID Connect
- OpenID Connect Profile for SCIM Services - (Optional) Defines how to use SCIM with OpenID Connect
- OpenID Connect Federation - (Optional) Defines how sets of OPs and RPs can establish trust by utilizing a Federation Operator
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 Core spec, write the title as
Core - 4.3.2 This is the title for the issue
<SpecAbbrev> right now are:
Link to the Issues
- All (All | Open ) - General issues not pertaining to a particular specification.
- Core (All | Open)
- Discovery (All | Discovery)
- Registration (All| Registration)
- Session Management (All | Open )
- Multiple Response Types (All | Open )
- Basic (All | Open)
- Implicit (All | Open)
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. (Command to use is on http://hg.openid.net/connect/ )
- 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