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. 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.
-- 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
http://blog.facilelogin.com
http://RampartFAQ.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
