OAuth 2 Scope Design Discuss iom

Session Topic: OAuth2 Scope Design Discussion

Thursday 4E

Convener: Eve Maler and Ajanta Adhikari

Notes-taker: Eve Maler

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

There are opportunities around OAuth scope and UMA scope interoperability.

There are user experience needs for standardized scope semantics.

In the near future, can we expect more standardized scopes because of more interoperable ways to convey them between resource servers and authorization servers?

Look at the SAML example; there are some standardizable attribute categories derived from regulations. These could map to reusable scopes.

OAuth is a framework, not a protocol; scopes come from the application level, not the OAuth level. Said another way, OAuth is a security mechanism for APIs, and doesn't say anything about the semantics of those APIs vs. its own semantics.

A useful concept Akamai uses is internal vs. external scopes, with token chaining -- not a tree but a set. Akamai re-maps scopes when resource locations change. Public (application/external) scopes are essentially part of the API.

We see authorization policy getting more complex! This seems to indicate a use case for UMA resource set registration vs. just plain single-level scopes.

It's always possible to define "flat" scopes that have infiormal relationships between them, a la the Salesforce scopes example. When is it valuable to make these relationships machine-readable? On-the-fly composition is the right rationale for structured scopes and/or resource sets. Google uses "+" for composition, e.g. "login+mail" (or similar). Standardizing such syntax could be valuable.

(Aside: "Access" vs. "delegation" is something UMA folks should discuss. Along with scopes, there's the question of passing the right identity to the resource server in the API call.)