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

[Prabath Siriwardena <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]>:
>
>
>
> On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart <[e-mail]>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)
>> [e-mail]*
>>
>>
>>
>>
>> From:        Prabath Siriwardena <[e-mail]>
>> To:        Justin Richer <[e-mail]>,
>> Cc:        "[e-mail] WG" <[e-mail]>
>> Date:        02/06/2013 10:31 AM
>> Subject:        Re: [OAUTH-WG] A question on token revocation.
>> Sent by:        [e-mail]
>> ------------------------------
>>
>>
>>
>>
>>
>> On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer <*[e-mail]*<[e-mail]>>
>> wrote:
>>
>> On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
>>
>>
>> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <*[e-mail]*<[e-mail]>>
>> 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*<http://tools.ietf.org/html/draft-ietf-oauth-revocation-04>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Mobile : *[phone]* <%2B94%2071%20809%206732>
>> *
>> **http://blog.facilelogin.com* <http://blog.facilelogin.com/>*
>> **http://RampartFAQ.com* <http://rampartfaq.com/>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> *[e-mail]* <[e-mail]>
>> *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Mobile : *[phone]* <%2B94%2071%20809%206732>
>> *
>> **http://blog.facilelogin.com* <http://blog.facilelogin.com/>*
>> **http://RampartFAQ.com* <http://rampartfaq.com/>
>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Mobile : [phone]
>> *
>> **http://blog.facilelogin.com* <http://blog.facilelogin.com/>*
>> *
>> *http://RampartFAQ.com* <http://rampartfaq.com/>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : [phone]
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Thanks & Regards,
Prabath

Mobile : [phone]

http://blog.facilelogin.com
http://RampartFAQ.com