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

[Justin Richer <[e-mail]>]

This, I think, points out that the RO is generally more concerned with 
revoking an authorization grant than a token itself, with the latter 
potentially encompassing several tokens. The revocation draft isn't 
really intended to solve that problem, as Torsten points out below.

  -- Justin

On 02/07/2013 03:46 AM, [e-mail] wrote:
>
> During the four grant types of Oauth,
>   1. authorization code: RO knows the authorization code upon which 
> access-tokens-to-be-revoked are issued
>   2. implicite flow: RO knows the access-tokens-to-be-revoked
>   3. password and client credential types: RO has no way of knowing 
> access tokens.
>
> So,IMO,  it is not proper for RO to revoke an each access token 
> individually,
> rather it could revoke some access tokens by specifying conditions, 
> such as client_id, time_period, scope
> Comments?
>
> Prabath Siriwardena <[e-mail]> ?? 2013-02-07 15:25:02:
>
> >
>
> > On Thu, Feb 7, 2013 at 12:49 PM, <[e-mail]> wrote:
> >
> > I guess RO could initiate access token revocation for a client by
> > including authorization code in the request to AS.
> > Comments?
> >
> > That creates a dependency on the grant type.
> >
> > Thanks & regards,
> > -Prabath
> >
> >
> >
> >
> >
> > [e-mail] ?? 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 <
> > [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 
> latteruse 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]> 
> wrote:
> > >
> > > On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
> > >
> > >
> > > On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <[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
> > >
> > > --
> > > 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
> > >
> > >
> > >
> > >
> > > --
> > > 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
> > > _______________________________________________
> > > 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
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth