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

[Prabath Siriwardena <[e-mail]>]

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 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]>
> 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