Specifically, the client will pretty much *always* revoke the
token asynchronously -- which is to say, without the RO (or RqP in
our case) authenticating at the AS. The revocation spec mentions
absolutely nothing about the RO taking action.
So I contend that revocation in UMA is still just as simple.
-- Justin
Oh wait, maybe I was reading 6749 and thinking I was reading 7009. Strike that, reverse it. :-/ The client can already ask to revoke the token asynchronously from its user.
Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Sat, Apr 15, 2017 at 4:25 PM, Eve Maler <eve@xmlgrrl.com> wrote:
https://github.com/KantaraInitiative/wg-uma/ issues/295
This was our token revocation discussion. It seemed so simple on our call on Thursday: Just define a new token type hint keyword, say "pct". But reading RFC 7009, I'm not sure that's quite the end of it.
Token revocation requires authenticating the identity of the resource owner at the authorization endpoint a la OAuth Sec 3.1. Of course, by analogy, that would be using the claims interaction endpoint for us, but we allow a lot more flexibility in our authorization process, e.g. pushing claims etc. And this isn't just because it's an asynchronous grant. So I think we need to do a bit more "surgery".
I can't think of any reason why the client shouldn't be able to go ahead and ask to revoke any RPT it has, even if the RqP isn't around. Is that legit?
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma