There Is No Scope – Doing Scope, Cliams the OIDC Way – IRL

There Are No Scopes On Using Scopes & Claims the OIDC Way

Tuesday 4J

Convener: Mark Dobrinic

Notes-taker(s): Mark Dobrinic

Tags for the session - technology discussed/ideas considered:

OAuth, Scopes, Claims

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

Inspired by the fact that the OAuth specification gives us the concept of "scope" but it is intentionally left unspecified, so everybody can use it as it fits best.

This was the original intent, the time as come where specific problems are trying to find a structured way of using scope to bind authorization data to tokens.

A short presentation introduces the concepts of

- scope as scope of access

- claims as statements that are asserted by an authority

- attributes that can be turned into a claim by some authority

- scope to represent a collection of claims, as standardized by OpenId Connect

OpenId Connect defines a number of scopes that expand to claims, i.e. requesting that particular scope equals asking for a set of claims.

Our take has taken this concept into a generic thing: allow an Authorization Server to define its own scopes, which each can expand to one or more claims.

Other current usages of scope include so called Dynamic Scopes (or Prefix Scopes) that try to bind an action to a transaction id, to be authorized by an end-user.

Discussion resulted in the notion that the use of scope in requesting tokens should be about carrying the intent that a client has for the requested token.

Including many claims in tokens should be carefully considered, because the authorization server must not be overloaded in the knowledge it has about clients and resource servers. The name "authorization server" could even be misleading, in the sense that it is the resource server that ultimately authorizes a request or not (based on the presented token).

It is mentioned that using tokens that expand into claims in a token would not replace the current use of scope with OAuth. Instead, it is an extension of the use of scopes, that makes use of existing patterns (in particular: the "scope" request parameter from OAuth and the "claims" request parameter from OpenId Connect)

Some discussion is about the proposed "structured_scope" approach from the OAuth Working Group, which tries to solve the transaction authorization case that is currently tried to be solved by different parties. Dynamic Scopes are solving that for PSD2, structured scopes could solve it in a different way, but the scope-as-claims pattern could also solve this by using the expected "value" part of the "claims" request parameter.

The session resulted in the conclusion that the discussion should be continued with other approaches.