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 minor
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 B
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
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 Key
