And as such, not easily elaborated over Twitter. The TL;DR is, a protocol artifact won’t solve that scenario- it just a heuristic and as such it can be handled out of band wit the exact same result.

One last data point. I once worked on a product that erroneously returned an equivalent parameter. It was a royal fuckup as most (MOST) developers baked the assumption that the RT was valid for that time in their code, & didn’t handle revocations- with disastrous runtime results

I understand you, my only point is if we have a expires_in referencing the access_token, why not a RT_expores_in referencing the RT?!

Assumptions of AT validity window are more often correct. The AT revocation/rejection is not as common a scenario as RT invalidation, we are only now starting to work on some scenarios (see stepup auth) whereas consent revocation (one way of revoking RTs is baked in core.

But the consent revocation should expires the AT too, right?!

The consent revocation yes, but that’s 1) just one of the ways in which an RT might be invalidated 2) in practice there’s no obvious way of propagating that, whereas the RT invalidation is easy.

Doesn't the same apply for AT?

The last tweet was meant to say that it does not :) I think we reached the limits of what can be said on Twitter - my suggestion would be to attend the next #oauth happy hour with @aaronpk and yours truly so we can discuss it real-time

Ok, thanks for listening to me…

The way I like to think about it is: If the client knows when the AT will (likely) expire, it can proactively refresh the token. There is nothing the client can do differently if it knows when the RT will (likely) expire.