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 <eve@xmlgrrl.com <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