On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer <jric...@mitre.org> wrote:
> > On 02/06/2013 10:13 AM, Prabath Siriwardena wrote: > > > > On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <jric...@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 <%2B94%2071%20809%206732> >> >> http://blog.facilelogin.com >> http://RampartFAQ.com >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://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
