I see the concern about keeping the validator API generic and not implicitly favoring JWT-style providers. The callback-based approach does seem more flexible, especially for opaque tokens or providers supporting revocation, where validity cannot be represented as a fixed timestamp. Perhaps one possible direction could be to support both:
An optional expiry timestamp for simple/static cases.
An optional callback (e.g., expired_cb) for dynamic validation.
This would allow JWT-based validators to remain lightweight while enabling more complex providers to implement custom revalidation logic. If enforcement is planned at statement start, integrating the callback mechanism in the same patch might also clarify the intended semantics.
