Difference between revisions of "OpenID Connect"

From IIW
Jump to: navigation, search
(Undo revision 3058 by Igiwydijok (Talk))
Line 1: Line 1:
'''Issue/Topic:''' OpenIDConnect Deep Dive  
'''Issue/Topic:''' OpenIDConnect Deep Dive  

Latest revision as of 12:34, 7 February 2011

Issue/Topic: OpenIDConnect Deep Dive

Session: Tuesday 5E

Conference: IIW-11 November 2-4, Mountain View, Complete Notes Page

Convener: Breno de Medeiros/ David Recordon

Notes-taker(s): Chuck Mortimore


OpenID Connect, OpenID Artifact Binding

Discussion notes:

Comparison and Contrasts between three proposals for a new generation of OpenID protocol based on Oauth2: The OpenID Artifact Binding (AB), The OpenID Connect proposal 1 (OIC1, by David Recordon, Facebook), and OpenID Connect proposal 2 (OIC2, by Breno de Medeiros, Google)

AB characteristics:

  • Allow to define request parameters by supplying a reference to a file containing a request descriptor, which allows for fixed URL-length requests
  • Provides bindings to all OpenID 2.0 extensions
  • Provides backward-compatibility of identifier
  • Provides a clear path to higher levels of assurance
  • Based on Oauth2 WebServer profile

OIC1/OIC2 characteristics:

  • Provides OpenID Connect flows for multiple Oauth2 profiles (Web Server, User-Agent, Assertion)
  • Support clients that are not capable to perform cryptographic operations
  • Establish a standard Oauth2-protected endpoint, called the UserInfo API endpoint
  • Binding of OpenID extensions TBD
  • Emphasis on new identifier format: binding between old and new identifiers must be provided by a defined account linking step
  • Higher levels of assurance path not described; however, because both OIC1 and OIC2 call for the user of standard JSON tokens to convey assertions, the AB security mechanisms are directly translatable in OIC1/OIC2

In addition, OIC1 describes a mechanism for session management.

Additional discussion on OIC1/OIC2:

  • Reconciled token format between OIC1 and OIC2: both now call for a signed JSON blob containing an expiration date, a user_id, and the Oauth2 access token, all signed; and additionally return the Oauth2 token separately for convenience of clients that are not crypto-savvy