> Sergey has the correct interpretation -- it's to prevent a class of oracle > attacks. > Think of it this way, if you go to revoke a token, and the token wasn't there > in the > first place, the end result is the same: the token's not there when you're > done. So > it's a 200 because the result is what you wanted even if the state going in > was wrong.
This highlights my point in my AD review: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/ ...that this is *not* revocation. It's invalidation or surrender (requested by the bearer of the token) -- revocation would be an action by another party to invalidate a token without the bearer's involvement. The usual defense against the sorts of attacks you're talking about is to make the failure conditions indistinguishable -- not to make success indistinguishable from failure. That is, you have two responses, success and failure, but the failure response doesn't say why. What, specifically, is the attack you're trying to defend against here, any why is this the best approach to that attack? I can't see how a "please invalidate this token" request can in any way take advantage of a "no" response to mount an attack. It's possible that there really is a threat here and that this is the right way to handle it, but I'd like to see that explained. Barry, Applications AD _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
