Request an ID Token and verify its signature. Will have to retrieve new keys from the OP to be able to verify the ID Token.
Successfully verify the ID Token signature, fetching the rotated signing keys if the 'kid' claim in the JOSE header is unknown.
rp-key-rotation-op-sign-key
Request an ID Token and verify its signature. Make a new authentication request and retrieve another ID Token and verify its signature.
Successfully verify both ID Token signatures, fetching the rotated signing keys if the 'kid' claim in the JOSE header is unknown.
The way I understand the descriptions
rp-key-rotation-op-sign-key expects the client to manually call whatever procedure to refresh the OP jwks_uri
rp-key-rotation-op-sign-key-native expects the client to refresh the OP jwks_uri based on a new key being returned
If this is not the case the tests are redundant, equal to one another.
If it is tho, both make the OP rotate keys when it issues the token exchange response and their descriptions are incorrect.
expected behaviour: rp-key-rotation-op-sign-key rotates right after issuing the first token exchange response so that the client can call its procedure. (similar to rp-key-rotation-op-enc-key)
The way I understand the descriptions
rp-key-rotation-op-sign-keyexpects the client to manually call whatever procedure to refresh the OP jwks_urirp-key-rotation-op-sign-key-nativeexpects the client to refresh the OP jwks_uri based on a new key being returnedIf this is not the case the tests are redundant, equal to one another.
If it is tho, both make the OP rotate keys when it issues the token exchange response and their descriptions are incorrect.
expected behaviour:
rp-key-rotation-op-sign-keyrotates right after issuing the first token exchange response so that the client can call its procedure. (similar to rp-key-rotation-op-enc-key)