What is OpenID Connect?
See http://openid.net/connect/faq/ for a set of answers to Frequently Asked Questions about OpenID Connect.
How is OpenID Connect different than OpenID 2.0?
OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly. OpenID Connect can also be extended to include more robust mechanisms for signing and encryption. Integration of OAuth 1.0a and OpenID 2.0 required an extension (called the OpenID/OAuth hybrid); in OpenID Connect, OAuth 2.0 capability is built into the protocol itself.
List of Specifications
Below are links to the HTML versions of the released copies of the 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 Clients dynamically discover information about OpenID Providers
- Dynamic Registration – (Optional) Defines how clients 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 back-channel communication between the OP and RPs being logged out
Below are links to the HTML versions of the released copies of the related implementer’s guides:
- Basic Client Profile – Simple subset of the Core functionality for a web-based Relying Party using the OAuth code flow
- Implicit Client Profile – Simple subset of the Core functionality for a web-based Relying Party using the OAuth implicit flow
A protocol migration specification has been finalized:
- OpenID 2.0 to OpenID Connect Migration 1.0 – Defines how to migrate from OpenID 2.0 to OpenID Connect
Finally, the OpenID Connect working group has started this new work:
- 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
The easiest way to monitor progress on the OpenID Connect 1.0 Specification is to join the mailing list at http://lists.openid.net/mailman/listinfo/openid-specs-ab.
Please note that while anyone can join the mailing list as a read-only recipient, posting to the mailing list or actively contributing to the specification itself requires the submission of an IPR Agreement. More information is available at http://openid.net/intellectual-property. Make sure to specify the working group as “OpenID AB/Connect”, because this group is a merged working group and both names must be specified.
The working group specification repository is kept at http://svn.openid.net/repos/specifications/connect/1.0/ . In this repository, only approved sub-versions are committed. If you want to live on the edge, go to http://hg.openid.net/connect/ where we keep edit by edit commits. These edits make it into SVN once they are approved by the editors.
- Monday Meetings
- When: Monday 3pm PT every other week: (See the google calendar below)
- Where: https://www3.gotomeeting.com/join/695548174
- Thursday meetings
- When: Thursday 7am PDT every other week: (See the google calendar below)
- Where: https://www3.gotomeeting.com/join/181372694
- GoToMeeting software is available on Mac, PC, iPhone, and Android Phone.
- Using VoIP option of GoToMeeting is preferred. If you have to absolutely use plain old telephone some reason, here is the US phone number: +1 (773) 897-3000.
- Please Note: Number of the participation to the call is limited to 15 most active members at the discretion of the chair due to the number of lines available.
To submit an issue to each specifications, use the following syntax in the Title.
<SpecAbbrev> <Section.Number> - <Description>
For example, to submit a comment on section 4.3.2 of Message spec, write the title as
Message 4.3.2 - This is the title for the issue
<SpecAbbrev> values at present are:
Link to the Issues
- Core (All | Open)
- Discovery (All | Discovery)
- Registraion (All| Registration)
- Session Management (All | Open )
- Implicit (All | Open)
- Basic (All | Open)
- All (All | Open ) – General issues not pertaining to a particular specification.
Working with the bitbucket repository
The working repository of this WG 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.)
- (If you do not already have one, create a Bitbucket userid).
- Tell Nat/Mike/John the userid – they will get you write privileges.
Then start working with the repository as:
- Clone the repository. (The 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 following:
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