Only the access token (or refresh token) represents the access grant (which includes scope). To extend the scope of an already granted authorization, the client must use the access token or refresh token to do so.
EHL On 4/1/10 8:15 PM, "Allen Tom" <a...@yahoo-inc.com> wrote: > Hi George - > > I¹m trying to figure out the re-scoping flow as well, to allow clients to > progressively upgrade their scopes over time. > > A potential pitfall is the scenario where multiple clients, share the same > client_id and secret. For instance, a developer might have both a website and > also an iphone app, and reuses the same client_id for both. > > Should the Service Provider keep the scopes in sync for both apps? If the > refresh_token is not passed to the re-auth flow, the Service Provider will > have a hard time determining which instance of the app is requesting the > upgraded scope. > > Perhaps this doesn't matter, because it can be argued that although there > might be multiple instances of the same client_id, it¹s all the same app > anyway. So maybe it¹s OK to upgrade the scopes for all instances of a given > client_id. > > Allen > > On 3/26/10 10:57 AM, "George Fletcher" <gffle...@aol.com> wrote: > >> >> >> It it sufficient for the client to just start a new web server flow and >> specify a new scope parameter that includes both "read buddylist" and "send >> IM"? The AS would then show Alice that she'd already approved "read >> buddylist" and just needed to approve "send IM"? This requires the client to >> keep track of all scopes requested for a given user:protected_resource. >> >> Another option might be to just allow the client to pass in the refresh_token >> (as that likely has the scoped embedded/associated with it). In this case the >> client could just ask for the new scope it wanted. >> >> Thoughts? Anyone else have a need for dynamic re-scoping? >> >> Thanks, >> George >> >> P.S. This flow is deployedas part of the AOL IM APIs. However, when >> dynamically adding an authorization, we only show the user what their being >> asked to consent to, not what they've done in the past. >> >> >> >> _______________________________________________ >> 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
