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 On 4/15/2017 7:30 PM, Eve Maler wrote:
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
mailto:eve@xmlgrrl.com> wrote: https://github.com/KantaraInitiative/wg-uma/issues/295 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 https://tools.ietf.org/html/rfc7009#section-2 authenticating the identity of the resource owner at the authorization endpoint a la OAuth Sec 3.1 https://tools.ietf.org/html/rfc6749#section-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?
*Eve Maler *Cell +1 425.345.6756 tel:%28425%29%20345-6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma