Re: [OAUTH-WG] A question on token revocation.

I guess RO could initiate access token revocation for a client by 
including authorization code in the request to AS.
Comments? 

oauth-bounces@ietf.org 写于 2013-02-07 02:32:28:

> Hi Torsten,
> 
> Thanks for your feedback.. I will submit a draft...
> 
> Thanks & regards,
> -Prabath

> On Wed, Feb 6, 2013 at 11:55 PM, Torsten Lodderstedt 
<torsten@lodderstedt.net
> > wrote:
> Hi Prabath,
> 
> we tried to address both use cases in the first revisions of the 
> draft. The API was well suited for client-driven revocation but not 
> the resource owner - driven use case. There are definitely 
> differences with respect to the protocol design, at least regarding 
> authentication and authorization of the respective actors. This made
> the spec more complex and caused ambiguities and confusion. 
> Moreover, the working group seemed not convinced by the the latter use 
case.
> 
> Therefore the working group decided to focus on the single use cases
> of the revocation by clients. This makes a lot of sense since this 
> interface is most important with respect to interoperability.
> 
> I'm focusing right now on finishing this draft. And the open issues 
> discussed on the list in the last couple of weeks illustrate that 
> even this poses a considerable amount of work. So I'm very reluctant
> to add support for a whole new use case at that point of the process.
> 
> If you feel this is an important use case worth an RFC, don't 
> hesitate to publish a new I-D.
> 
> regards,
> Torsten.
> 
> Am 06.02.2013 um 16:37 schrieb Prabath Siriwardena <prabath@wso2.com>:

> 

> On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart <lainhart@us.ibm.com> 
wrote:
> > Resource owner needs to know the consumer key (represents the 
> OAuth Client app) & scope to revoke the access token for a given 
client.  

> I see - you're saying that requiring client credentials on the end 
> point is the problem?
> 
> In fact what I meant was - when RO authorizes the an access token 
> for client for particular scope. Those information are kept at the AS.
> 
> Now - if the RO want to revoke access from the client - the RO needs
> to authenticate him self to the AS and pass the consumer key and the
> scope. So AS can revoke access.
> 
> Thanks & regards,
> -Prabath
>  
> 
> 
> 
> 
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainhart@us.ibm.com
> 
> 
> 
> 
> 

> From:        Prabath Siriwardena <prabath@wso2.com> 
> To:        Justin Richer <jricher@mitre.org>, 
> Cc:        "oauth@ietf.org WG" <oauth@ietf.org> 
> Date:        02/06/2013 10:31 AM 
> Subject:        Re: [OAUTH-WG] A question on token revocation. 
> Sent by:        oauth-bounces@ietf.org 
> 
> 
> 
> 

> On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer <jricher@mitre.org> wrote: 

> 
> On 02/06/2013 10:13 AM, Prabath Siriwardena wrote: 
> 
> 
> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <jricher@mitre.org> wrote: 

> These are generally handled through a user interface where the RO is
> authenticated directly to the AS, and there's not much need for a 
> "protocol" here, in practice. 
> 
> Why do you think leaving access token revocation by RO to a 
> proprietary API is a good practice ? IMO this an essential 
> requirement in API security. 
> I think it makes more sense in the same way that having a 
> "proprietary" UI/API for managing the user consent makes sense: 
> unless you're doing a fully dynamic end-to-end system like UMA, then
> there's not much value in trying to squeeze disparate systems into 
> the same mold, since they won't be talking to each other anyway. 
> 
> This is required in distributed setup for each API platform from 
> different vendors to perform in an interop manner. 
>   
> 
> And since you refer to it as an "API", what will the RO be using to 
> call this API? Is there a token management client that's separate 
> from the OAuth client? 
> 
> I didn't get your question right... If you meant the how to invoke 
> revocation end point, the the resource owner needs to know the 
> consumer key (represents the OAuth Client app) & scope to revoke the
> access token for a given client.  
> 
> 
> 
> IMHO token revocation done my RO is more practical than token 
> revocation done by the Client. 
> They're both valid but require different kinds of protocols and 
> considerations. This token revocation draft is meant to solve one 
> problem, and that doesn't mean it can or should solve other 
> seemingly related problems.
> 
> If you would like to see the RO-initiated token revocation go 
> through (not grant revocation, mind you -- that's related, but 
> different), then I would suggest that you start specifying exactly 
> how that works. I predict it will be problematic in practice, 
> though, as the RO often doesn't actually have direct access to the 
> token itself. 
> 
> Resource owner needs to know the consumer key (represents the OAuth 
> Client app) & scope to revoke the access token for a given client.  
> 
>   
> 
>   
> There are larger applications, like UMA, that have client and PR 
> provisioning that would allow for this to be managed somewhat 
> programmatically, but even in that case you're still generally doing
> token revocation by a "client" in some fashion. In UMA, though, 
> several different pieces can play the role of a "client" at 
> different parts of the process.
> 
> Revoking a scope is a whole different mess. Generally, you'd want to
> just revoke an existing token and make a new authorization grant 
> with lower access if you don't want that client getting that scope 
> anymore. If you just want to downscope for a single transaction, you
> can already do that with either the refresh token or token chaining 
> approaches, depending on where in the process you are. The latter of
> these are both client-focused, though, and the RO doesn't have a 
> direct hand in it at this point. 
> 
> Why do you think it a mess. If you revoke the entire token then 
> Client needs to go through the complete OAuth flow - and also needs 
> to get the user consent. If RO can  downgrade the scope, then we 
> restrict API access by the client at RS end and its transparent to 
> the client. 
> 
> 
> Downgrading the scope of tokens in the wild is hardly transparent to
> the client (stuff that it expects to work will suddenly start to 
> fail, meaning that most clients will throw out the token and try to 
> get a new one), and in a distributed system you've got to propagate 
> that change to the RS. If you bake the scopes into the token itself 
> (which many do) then you actually *can't* downgrade a single token, 
anyway. 
> 
> Yes.. that is the expected behavior. I mean the process is 
> transparent. Client will notice at runtime. 
> 
> Thanks & regards, 
> -Prabath 
>   
> 
>  -- Justin 
> 
> 
> Thanks & regards, 
> -Prabath 
>   
> 
> 
>  -- Justin 
> 
> 
> On 02/06/2013 04:35 AM, Prabath Siriwardena wrote: 
> I am sorry if this was already discussed in this list..  
> 
> Looking at [1] it only talks about revoking the access token from the 
client. 
> 
> How about the resource owner..? 
> 
> There can be cases where resource owner needs to revoke an 
> authorized access token from a given client. Or revoke an scope.. 
> 
> How are we going to address these requirements..? Thoughts 
appreciated... 
> 
> [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 
> 
> -- 
> Thanks & Regards,
> Prabath 
> 
> Mobile : +94 71 809 6732 
> 
> http://blog.facilelogin.com
> http://RampartFAQ.com 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> 
> 
> -- 
> Thanks & Regards,
> Prabath 
> 
> Mobile : +94 71 809 6732 
> 
> http://blog.facilelogin.com
> http://RampartFAQ.com 
> 
> 
> 
> 
> -- 
> Thanks & Regards,
> Prabath 
> 
> Mobile : +94 71 809 6732 
> 
> http://blog.facilelogin.com
> http://RampartFAQ.com_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

> 

> 
> -- 
> Thanks & Regards,
> Prabath
> 
> Mobile : +94 71 809 6732 
> 
> http://blog.facilelogin.com
> http://RampartFAQ.com
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 

> 
> -- 
> Thanks & Regards,
> Prabath
> 
> Mobile : +94 71 809 6732 
> 
> http://blog.facilelogin.com
> http://RampartFAQ.com_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth