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

[Dick Hardt <[e-mail]>]

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.

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

> 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
>
>
> On Mon, May 10, 2010 at 10:39 PM, John Panzer <[e-mail]> wrote:
> > 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 <[e-mail]> wrote:
> >> Are there actual use cases for this? Either way sounds like it belongs
> in an extension.
> >>
> >> EHL
> >>
> >>> -----Original Message-----
> >>> From: Marius Scurtescu [mailto:[e-mail]]
> >>> Sent: Monday, May 10, 2010 12:49 PM
> >>> To: Eran Hammer-Lahav
> >>> Cc: Dick Hardt; OAuth WG ([e-mail])
> >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token
> >>>
> >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav
> >>> <[e-mail]> wrote:
> >>> > 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
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: [e-mail] [mailto:[e-mail]] On
> >>> >> Behalf Of Dick Hardt
> >>> >> Sent: Sunday, May 09, 2010 7:19 PM
> >>> >> To: OAuth WG ([e-mail])
> >>> >> 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 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.
> >>> >>
> >>> >> _______________________________________________
> >>> >> OAuth mailing list
> >>> >> [e-mail]
> >>> >> https://www.ietf.org/mailman/listinfo/oauth
> >>> > _______________________________________________
> >>> > OAuth mailing list
> >>> > [e-mail]
> >>> > https://www.ietf.org/mailman/listinfo/oauth
> >>> >
> >> _______________
> >
> > --
> > --
> > John Panzer / Google
> > [e-mail] / abstractioneer.org / @jpanzer
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>