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