A Map for OpenID Connect 1

IIW is rapidly approaching.

We plan to take advantage of face to face discussions on the around the next version of openID.

For those attending and others I want to point to the various potions of the spec work so that people have that in hand for IIW.

One of the changes from openID 2.0 is that the new specification is more modular.

The following diagram illustrates the components and links to the specs:


(Click on the diagram to see each specifications.)

Everything is built on top of OAuth 2.0 and the Bearer Token Profile of OAuth.

We are supporting multiple OAuth Flows for different device types.

The heart of OpenID Connect is the Core spec that describes the abstract protocol.

We have created bindings for several of the OAuth flows.
These include:
  1. Artifact, a optimized flow for mobile devices that have URL length limitations.
  2. Web App/Code Grant, a strait forward and simple binding for web servers.
  3. Smart Client, a binding for Smart user agents (in development)
JSON Web Token is used by Core.  It has Four parts:
  1. JSON Web Token, The core token spec
  2. JSON Web Signature, The signature spec
  3. JSON Web Encryption,  The encryption spec
  4. JSON Web Key, A simple way to represent Public Keys

Discovery of user identifiers such as email for URI is performed by a profile of Simple Web Discovery

Session Management is currently a separate spec, however it may be folded into Core.

Revised: Core 1.0d03 incorporates the session management endpoints and eliminates some duplication.

Outstanding Issues

We are hoping to use our face 2 face time around IIW to resolve some of the outstanding issues:

  1. Claimed ID type.   We have two proposals, one for a single URL and another for a two part identifier where the user_ID and the IdP/OP identifier are separate.
  2. An extension for PAPE/Authentication Context.   This will be required for government and other higher security applications.
  3. A formal spec for the User Info Endpoint and defining the base attribute schema.
  4. Defining how other extensions can be added.
  5. Defining a syntax for requesting sets of claims from trusted sources.

We will be producing a implementers guide to make it easier for people to build clients without having to wade through all of the separate specs.

Expect an update after IIW in May.

John B.

openid connect core json web token json web signature json web encryption json web key simple web discovery session management web app binding user agent binding artifact binding Image Map