Gov Use of OAUTH2, OPEN ID Connect, UMA? (2G1)

Government use of OAUTH (2G1)

Convener: Anil John

Notes-taker(s): Eve

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

The session centered on a discussion of what it would mean to profile OAuth as an authorization mechanism, vs. OpenID Connect as an identity API protected by OAuth, for various government use cases. The consensus by experts was that the latter would have to be profiled to get the desired effect, though this would surface some items that were generic to OAuth.

We also discussed deltas between OpenID Connect and Facebook's identity API.

We also constructed a comparison in Venn form of OAuth, OpenID Connect, and UMA (attached). Here is an extended version of the text in the diagram:

OAuth, OpenID Connect, and UMA share:

• Delegated constrained access (all provided by OAuth itself)

OAuth and OpenID Connect share:

• Pairwise server-client authorization
• "Three-legged" Alice-to-Alice sharing (she has a login on both the server and client sides)

OpenID Connect and UMA share:

• Trusted claims (provided by OpenID Connect itself)

UMA and OAuth share:

• Protection of arbitrary web APIs

OpenID Connect uniques solves:

• SSO
• Login session and login-time attribute exchange
• Federated identifier

UMA uniquely solves:

• Third-party access (allowing a user to proactively and asynchronously offer claims-based access)
• Centralized authorization to multiple data sources