Rotation of signing keys can be accomplished with the following approach. The signer publishes its keys in a JWK Set at its
jwks_urilocation and includes the
kidof the signing key in the JOSE Header of each message to indicate to the verifier which key is to be used to validate the signature. Keys can be rolled over by periodically adding new keys to the JWK Set at the
jwks_urilocation. The signer can begin using a new key at its discretion and signals the change to the verifier using the
kidvalue. The verifier knows to go back to the
jwks_urilocation to re-retrieve the keys when it sees an unfamiliar
kidvalue. The JWK Set document at the
jwks_uriSHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a smooth transition.
The “signer can begin using a new key at its discretion” seems potentially problematic - discussion within the certification (around a test intended to test RPs rotating keys, see https://www.heenan.me.uk/~joseph/oidcc_test_desc-phase1.html#OP_Rotation_RP_Sig ) revealed that OPs in larger distributed deployments will in some cases not react immediately to keys being added and a new kid being found. For example to prevent a DoS attack an OP may well decide not to refetch a JWKS it has fetched in the last 60 seconds.
I would suggest tweaking the text so that “The signer can begin using a new key at its discretion” becomes something like “The signer should wait at least a few minutes after it publishes the new key and then can begin using a new key at its discretion”