Subject: [OAUTH-WG] modifying the scope of an access token

From: Dick Hardt <[email-masked]>
Date: Sun, 9 May 2010 19:19:16 -0700

There has been some discussion about modifying the scope of the access token during a refresh. Perhaps we can add another "method" to what the AS MAY support that allows modifying the scope of an access token. Type of request is "modify" and the scope parameter is required to indicate the new scope required. Suggested copy below:

type
	REQUIRED. The parameter value MUST be set to modify

client_id
	REQUIRED. The client identifier as described in Section 3.4.

client_secret
	REQUIRED if the client was issued a secret. The client secret.

refresh_token
	REQUIRED. The refresh token associated with the access token to be refreshed.

scope
	REQUIRED. The new scope of the access request expressed as a list of space-delimited strings. The value of the scope parameter is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds additional access range to the requested scope.

secret_type
	OPTIONAL. The access token secret type as described by Section 8.3. If omitted, the authorization server will issue a bearer token (an access token without a matching secret) as described by Section 8.2.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 22:17:14 -0700

This would only work for the client credentials flow (because you keep the same authorization source). For all other flows you are breaking the authorization boundaries.

What would be useful is to allow asking for more scope. For example, when asking for a token (the last step of each flow), also include a valid token to get a new token with the combined scope (new approval and previous).

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dick Hardt
> Sent: Sunday, May 09, 2010 7:19 PM
> To: OAuth WG ([email-masked])
> Subject: [OAUTH-WG] modifying the scope of an access token
> 
> There has been some discussion about modifying the scope of the access
> token during a refresh. Perhaps we can add another "method" to what the
> AS MAY support that allows modifying the scope of an access token. Type of
> request is "modify" and the scope parameter is required to indicate the new
> scope required. Suggested copy below:
> 
> type
> 	REQUIRED. The new scope of the access request expressed as a list
> of space-delimited strings. The value of the scope parameter is defined by
> the authorization server. If the value contains multiple space-delimited
> strings, their order does not matter, and each string adds additional access
> range to the requested scope.
> 
> secret_type
> 	OPTIONAL. The access token secret type as described by Section 8.3.
> If omitted, the authorization server will issue a bearer token (an access token
> without a matching secret) as described by Section 8.2.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 10 May 2010 12:48:30 -0700

> This would only work for the client credentials flow (because you keep the same authorization source). For all other flows you are breaking the authorization boundaries.

If the requested scope is a subset of the original scope associated
with the refresh token then it should be acceptable, right?

This would allow a client to request a larger set of scopes, needed
for all API calls need for its function, but then get sub-scoped
access tokens, particular to each API. This will prevent an API from
receiving a too powerful access token. A compromised API could use
access tokens to place calls against other APIs, but not if it is
narrowly scoped.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 10 May 2010 19:51:25 -0700

Are there actual use cases for this? Either way sounds like it belongs in an extension.

EHL

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Monday, May 10, 2010 12:49 PM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] modifying the scope of an access token
> 
> > This would only work for the client credentials flow (because you keep the
> same authorization source). For all other flows you are breaking the
> authorization boundaries.
> 
> If the requested scope is a subset of the original scope associated with the
> refresh token then it should be acceptable, right?
> 
> This would allow a client to request a larger set of scopes, needed for all API
> calls need for its function, but then get sub-scoped access tokens, particular
> to each API. This will prevent an API from receiving a too powerful access
> token. A compromised API could use access tokens to place calls against
> other APIs, but not if it is narrowly scoped.
> 
> Marius
> 
> >
> > What would be useful is to allow asking for more scope. For example, when
> asking for a token (the last step of each flow), also include a valid token to
> get a new token with the combined scope (new approval and previous).
> >
> > EHL
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Dick Hardt
> >> There has been some discussion about modifying the scope of the
> >> access token during a refresh. Perhaps we can add another "method" to
> >> what the AS MAY support that allows modifying the scope of an access
> >> token. Type of request is "modify" and the scope parameter is
> >> required to indicate the new scope required. Suggested copy below:
> >>
> >> type
> >>       REQUIRED. The new scope of the access request expressed as a
> >> list of space-delimited strings. The value of the scope parameter is
> >> defined by the authorization server. If the value contains multiple
> >> space-delimited strings, their order does not matter, and each string
> >> adds additional access range to the requested scope.
> >>
> >> secret_type
> >> If omitted, the authorization server will issue a bearer token (an
> >> access token without a matching secret) as described by Section 8.2.
> >>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 10 May 2010 22:21:53 -0700

I don't know of use cases, but if we are going to have this as a capability in the spec, then here is a suggested mechanism. 

-- Dick

---

From: John Panzer <[email-masked]>
Date: Mon, 10 May 2010 22:39:43 -0700

Yes; a service that does a one time configuration step, requiring
extensive access, followed by an ongoing lower level of access (say,
read-only).  Lowering access means it only needs to store low-risk
tokens in its data store, limiting exposure (and liability).

On Monday, May 10, 2010, Eran Hammer-Lahav <[email-masked]> wrote:
> _______________

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: David Recordon <[email-masked]>
Date: Mon, 10 May 2010 22:43:17 -0700

I'm wondering if this could be achieved by adding an optional scope
parameter to the existing refresh request versus creating a new
request type. Both because Dick's proposed text requires a refresh
token and it seems like services worried about this sort of risk would
not want to issue long lived access tokens.

--David

---

From: John Panzer <[email-masked]>
Date: Mon, 10 May 2010 23:52:16 -0700

(Note that in my use case, it's actually the client who wants to dispose of
its dangerous full-access token as quickly as possible, retaining only the
least-authority token it needs to continue its ongoing work.  This would be
the case even if the token granting service is handing out tokens like free
candy.)

On Mon, May 10, 2010 at 10:43 PM, David Recordon <[email-masked]>wrote:

> with the
> >>> >>       REQUIRED. The refresh token associated with the access token
> to
> >>> >> be refreshed.
> >>> >>
> >>> >> scope

---

From: David Recordon <[email-masked]>
Date: Tue, 11 May 2010 00:01:29 -0700

Yes. In the case of an authorization server handing out tokens like
free candy, it's unlikely that it would implement the ability to
restrict scope on a token it already issued.

Thus my argument is that it seems like this method would be
implemented by authorization servers who make use of refresh tokens.

On Mon, May 10, 2010 at 11:52 PM, John Panzer <[email-masked]> wrote:
>> >>> for all API

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 11 May 2010 00:21:07 -0700

Are you actually (planning on) writing something like this?

EHL

> From: John Panzer [mailto:[email-masked]]
> Sent: Monday, May 10, 2010 10:40 PM
> To: Eran Hammer-Lahav
> Cc: Marius Scurtescu; OAuth WG ([email-masked])
> Yes; a service that does a one time configuration step, requiring extensive
> access, followed by an ongoing lower level of access (say, read-only).
> Lowering access means it only needs to store low-risk tokens in its data store,
> limiting exposure (and liability).
> 
> >> access tokens to place calls against other APIs, but not if it is narrowly
> scoped.
> >>
> >> Marius
> >>
> >> >
> >> asking for a token (the last step of each flow), also include a valid
> >> token to get a new token with the combined scope (new approval and
> previous).
> >> >
> >> > EHL
> >> >
> >> >> access token during a refresh. Perhaps we can add another "method"
> >> >> to what the AS MAY support that allows modifying the scope of an
> >> >> access token. Type of request is "modify" and the scope parameter
> >> >> is required to indicate the new scope required. Suggested copy below:
> >> >>
> >> >> type
> >> >> to be refreshed.
> >> >> list of space-delimited strings. The value of the scope parameter
> >> >> is defined by the authorization server. If the value contains
> >> >> multiple space-delimited strings, their order does not matter, and
> >> >> each string adds additional access range to the requested scope.
> >> >>
> >> >> secret_type

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 May 2010 10:34:17 -0700

John / David: is this a feature you would want to implement? If no one wants
it, we can drop it.

On Mon, May 10, 2010 at 11:52 PM, John Panzer <[email-masked]> wrote:

>> token to
>> is

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 May 2010 10:35:34 -0700

My design preference would be to have a new request type. A AS could then
support or not support the feature, and it keeps refresh as refresh rather
than overloading it.

---

From: Luke Shepard <[email-masked]>
Date: Sun, 16 May 2010 13:01:28 -0700

So, you want to give developers the option to reduce the abilities of their token after it's already been issued? I have never heard a developer ask for this feature.

Beyond the general principle of "least-authority", can you describe a specific case where this would be useful? Are you talking about transferring tokens to a third party, or maintaining multiple tokens of different scopes within the same client?

On May 16, 2010, at 10:34 AM, Dick Hardt wrote:

John / David: is this a feature you would want to implement? If no one wants it, we can drop it.

On Mon, May 10, 2010 at 11:52 PM, John Panzer <[email-masked]<mailto:[email-masked]>> wrote:
(Note that in my use case, it's actually the client who wants to dispose of its dangerous full-access token as quickly as possible, retaining only the least-authority token it needs to continue its ongoing work.  This would be the case even if the token granting service is handing out tokens like free candy.)

On Mon, May 10, 2010 at 10:43 PM, David Recordon <[email-masked]<mailto:[email-masked]>> wrote:

--David

On Mon, May 10, 2010 at 10:39 PM, John Panzer <[email-masked]<mailto:[email-masked]>> wrote:
> On Monday, May 10, 2010, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
>>> From: Marius Scurtescu [mailto:[email-masked]<mailto:[email-masked]>]
>>> Cc: Dick Hardt; OAuth WG ([email-masked]<mailto:[email-masked]>)
>>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>> >> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>>> >> Behalf Of Dick Hardt
>>> >> To: OAuth WG ([email-masked]<mailto:[email-masked]>)
>>> >> [email-masked]<mailto:[email-masked]>
>>> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]> / abstractioneer.org<http://abstractioneer.org/> / @jpanzer
> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

<ATT00001..txt>

---

From: Joseph Holsten <[email-masked]>
Date: Sun, 16 May 2010 15:41:26 -0500

Narrowing scope is one of the most common tools of object-capability systems. It makes it much cheaper to keep deputies from being confused. Check out Ben Laurie, Mark Miller and Caja.

But I sure don't care enough to implement.

On May 16, 2010, at 3:01 PM, Luke Shepard wrote:

>> On Mon, May 10, 2010 at 10:43 PM, David Recordon <[email-masked]> wrote:
>> >>> <[email-masked]> wrote:

---

From: George Fletcher <[email-masked]>
Date: Sun, 16 May 2010 20:57:25 -0400

I'm definitely interesting in the ability to change the scope 
"dynamically", replacing an existing access token with a new access 
token. We use something very similar today in the AOL service APIs.

One question in regards to your proposal. If the client asks for a scope 
that the user hasn't approved... how would that flow work (using either 
the modify endpoint or the existing token endpoint)? It seems like the 
client needs to send the user back to the authorize endpoint with the 
new scope in order for the user to give consent.

It would also be good if the host could identify which scope is needed 
when the client performs some action that is not authorized.

Thanks,
George

On 5/16/10 1:34 PM, Dick Hardt wrote:
>     (Note that in my use case, it's actually the client who wants to
>     dispose of its dangerous full-access token as quickly as possible,
>     retaining only the least-authority token it needs to continue its
>     ongoing work.  This would be the case even if the token granting
>     service is handing out tokens like free candy.)
>
>     On Mon, May 10, 2010 at 10:43 PM, David Recordon
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         On Mon, May 10, 2010 at 10:39 PM, John Panzer
>         <[email-masked] <mailto:[email-masked]>> wrote:
>         > On Monday, May 10, 2010, Eran Hammer-Lahav
>         <[email-masked] <mailto:[email-masked]>> wrote:
>         >>> <[email-masked] <mailto:[email-masked]>> wrote:
>         >>> >> From: [email-masked]
>         <mailto:[email-masked]> [mailto:[email-masked]
>         <mailto:[email-masked]>] On
>         >>> >> Behalf Of Dick Hardt
>         >>> >> To: OAuth WG ([email-masked] <mailto:[email-masked]>)
>         >>> >>       REQUIRED. The refresh token associated with the
>         access token to
>         >>> >> be refreshed.
>         >>> >>
>         >>> >> scope
>         >>> >> [email-masked] <mailto:[email-masked]>
>         >>> > [email-masked] <mailto:[email-masked]>
>         > [email-masked] <mailto:[email-masked]> /
>         abstractioneer.org <http://abstractioneer.org> / @jpanzer
>         > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>