It used to be simply expires_at but after discussion on the list it was
changed to client_secret_expires_at, since the client's secret is the most
likely part to expire and need to be refreshed. Of course this refresh makes
the most sense if you're implementing the management spec where you can
Yes the JWKS expiry is logically controlled by the client. If it is going to
roll those keys it should be using a jwks_uri if there is no management API to
push a new JWKS.
In general symmetric client secrets create key management problems. My
preference is to move to asymmetric keys.
John
Okay, I see 'Changed expires_at to client_secret_expires_at and
issued_at to client_id_issued_at for greater clarity.' in the document
history for -11 (full 'management' was in the draft back then).
But to me, it doesn't improve clarity. And it seems limiting. But I seem to
be in the minority of
Why does expiration only apply to the client secret[1]? If there's a need
for the AS to set an expiration, isn't it broader than that and apply to
the whole client or the client id? If there's a need to signal an
expiration time on the client secret, doesn't it follow that the client's
JSON Web
