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 <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 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl