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