CLAIMS Vis-à-vis Scopes in OAuth & Open ID

Claims Vis-à-Vis Scopes in OAuth & OpenID

Thursday 14A

Convener: Travis Spencer, Curity

Notes-taker(s): Travis Spencer

Tags for the session - technology discussed/ideas considered:

oauth, scopes, openid, oidc, openid connect, claims, scope

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

In this talk, Travis led a discussion about his and his team's learnings about the relationship of claims and scopes. He stated that "scopes are a group of claims". He showed how the precedence for this is set in OpenID Connect (OIDC), and suggested that the idea be extended to plain OAuth. This would allow for arbitrary scopes to be created that contain various claims.

To justify this somewhat novel and controversial idea, he explained what claims are: A statement asserted by some entity (the asserting party) about another (the subject). These are only believable and acceptable if the asserting parting is trusted. He then explained what attributes are and that these are inputs to claims. They only become claims when an asserting party asserts them. A claim can be made up of many attributes and the values can be transformed into various types of objects (Boolean values, numbers, string, or complex objects).

When a scope is a group of claims, the administrator of the OP/AS need only associate scopes to a client since a claim will always be in at least one scope. Claims are mapped into a "sink" on a per client basis.

A "sink" of claims is the various places where claims may end up. These include an ID token and user info as defined by OIDC. They can also be mapped to an access token or an access token only for a certain API / RS.

There are many sources for claims. The obvious one are data sources, but others exist. Travis listed a few including authentication attributes, static text, etc.

Users / RO consent to scopes (if it is an empty group) but typically the claims in the scope.

Claims input / output are defined for all OIDC flows (code, implicit, and hybrid). Input is done using the claims request parameter using its defined query language. This is needed for all other message exchanges with the OP/AS (like on token exchange, refresh, introspect, etc.). Travis planned to specify this and present it at a subsequent IETF OAuth working group meeting.

In a claims-based system, the need for scopes goes away. Until the system is totally claims-based, however, access control can continue to be done on scopes (which are less expressive). If the client or RS is claims-aware, it can make more fine-grained access control by looking at the claim names and/or claim values.