OpenID Connect – The Intro

OpenID Connect (T2B)

Convener: Pam Dingle & Justin Richer

Notes-taker(s): Paul Madsen Tags for the session - technology discussed/ideas considered:

Elevator pitch – protocol framework based on OAuth – adds an identity layer to bare bones OAuth 2.0

The features of OpenID Connect can be divided into

a)   those features required for a full platform (e.g. discovery & client registration)

b)  standardization of identity pieces (e.g. UserInfo endpoint, id_token)

Note: some of the features defined in OpenID Connect are being fed back into the OAuth WG working on evolution of OAuth 2.0 Difference between a client & relying party? A relying party makes a decision based on a token/assertion it receives from elsewhere (an Idp). A client simply uses the token on an API call.

Justin went through the 3-party flow User RP                                                          OP                      (consumes tokens & attributes)                                                (issued tokens)

OpenID 2.0 – focused on front-channel

OAuth 2.0 – focused on back-channel

OpenID Connect – closer to OAuth 2.0

OP returns
 * id_token
 * JWT carries issuer, userid etc
 * Logically similar to SAML assertion
 * access token
 * Used on API call to UserInfo to retrieve attributes
 * Theoretically also used on calls to arbitrary APIs

Pam makes the point that OAuth & OpenID Connect makes different assumptions about how to apportion complexity between the OP/IdP & RP/SP than does SAML.

Question – what is the diff between the info in the id_token and that returned by the UserInfo? The former is bound to a session, with a small set of claims, the latter more long-lived.

OpenID Request Object allows relying party to describe its conditions Phil Hunt asks about live deployments. Mike replied with description of ongoing interop tests at http://osis.idcommons.net