> For providers using opaque tokens or introspection APIs where an 'exp' claim might be missing, the API remains
compatibleby 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.
