> For providers using opaque tokens or introspection APIs where an 'exp' claim > might be missing, the API remains compatible by allowing the validator to > return DT_NOBEGIN.
I don't think this is a good answer: the OAuth validator API went to the trouble of introducing a generic infrastructure with the explicit goal to work any OAuth provider, and now this proposes a change that limits a new API to some of them, while it wouldn't be more difficult to propose a generic API that works for everything. Let me rephrase the question: why is this a better approach than introducing an additional validator callback method, expired_cb? * it returns if the current OAuth token is expired or not * if it's NULL, nothing happens, so there's an easy upgrade path for validator in PG19 * for JWT validators with a clear expiry date, all they have to do is to store the expiry date in a global variable and then check if we passed that time in the new callback * alternatively, this callback could return the current expected expiry date, and the calling code could check it, but I think that's overcomplicating And in both cases, I think handling of the value/callback should be part of the patch - only providing an API and then doing nothing with it would set wrong expectations.
