Comment 15 for bug 1287301

d-w-chadwick , robert-clark : Based on the fix in https://review.openstack.org/#/c/78241/ , it looks like if the token is validated once and put in the cache, then after that the token is valid for the entire cache period (token_cache_time, which defaults to 5 mins) even if the token is revoked.

With PKI tokens, we've now got the revocation list... should auth_token be checking the revocation list for both UUID and PKI tokens?

With the latest change to set the revocation_cache_time to 5 minutes, then if a deployment is using the defaults there's nothing to gain by checking the revocation list... it'll be just as out of date as the cache. If someone was willing to set a lower time for revocation_cache_time then they'd have the shorter valid period for tokens.

What I'm trying to figure out is -- if we take the fix in https://review.openstack.org/#/c/78241/ will that provide more flexibility for the deployer to pick how they want revocations to work with caching? They can set revocation_cache_time to 10 seconds and tokens will be valid for 10 seconds after they're revoked... but they can already do the same thing by setting a short cache time, and then the code would be using the normal flow for UUID tokens which validates them against keystone rather than getting the revocation list.