Subject: [OAUTH-WG] Re-scoping OAuth access tokens

From: George Fletcher <[email-masked]>
Date: Fri, 26 Mar 2010 13:57:49 -0400

Hi,

One of the features of the existing OAuth Session Extension is a method 
by which a client can request additional authorizations/scopes to those 
it's already been granted by the user, and receive a single access token 
that embodies the intersection of the approved scopes.

An example use case is as follows...

1. Alice visits a new site (http://hikingsite.example.com) and logs in
2. The site has integrated a widget that allows Alice to see her 
buddylist so she can keep track of her friends while exploring the site
3. Alice needs to give consent for http://hikingsite.example.com to 
access her buddylist (normal web delegation flow)
     -- this consent just gives the site access to Alice's buddylist
4. At some point later, Alice sees a great trail she'd like to hike with 
one of her friends online and wants to send Bob an IM
5. Now the site needs permission to send an IM on Alice's behalf to Bob 
with a link to the trail

In the current OAuth draft spec, how does http://hikingsite.example.com 
increase it's scope for Alice at Alice's IM provider so that it can both 
read (the buddy list) and write (send IMs)?

It seems to me that the AS needs to remember the 
user:scope:client:protecte_resource mapping so that it knows what the 
user has consented to, and then allow the user to revoke that consent at 
sometime in the future.

It also seems to me that the client has to remember which scopes it's 
asked for based on user:scope:protected_resource.

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.