Key rollover for JWK Thumbprint option in SIOP?
Issue #1437
closed
It came up few times in recent discussions that an option to use JWK thumbprint as a cryptographically resolvable identifier in SIOP would be much more powerful if there was an option to do key rotation. I honestly don’t know if it is possible or not. I think there was a proposal for multiple subs in SIOP in last year, but thought of opening the issue as a placeholder.
Comments (4)
-
Account Deactivated
-
Account Deactivated
There are other mechanisms besides JWK thumbprint (such as
did:key) which also do not support rotation.An RP with HTTPs metadata could advertise an endpoint to rotate keys as a metadata key. This would be (if you squint) similar to https://w3c.github.io/webappsec-change-password-url/.
Using the secevent subject identifiers might not allow us to indicate directionality, but is worth exploring. I suspect we would want to nest to prove control of the old and new keys.
If a RP does not have a hosted endpoint but wants to support key rotation, they should probably mandate the use of an identifier that has the appropriate properties inherently, aka no immediate or thumbprint reference identifiers for keys.
-
Account Deactivated
Also, since this would effectively let you change subjects, it should only be supported for pseudonymous subjects specific to a RP/sector identifier. Otherwise, you are effectively forking control and will make compromise harder to detect and recover from in the case of key compromise.
-
reporter
- changed status to closed
don't think this is fundamental to the protocol right now.
- Log in to comment
I think the difficulty here would be that the rotation event would require an authorization event (and hence effectively a challenge/response protocol) and so that additional protocol would need to be specified now to make it work. The one idea I have that might make this a bit easier to defer would be to build the subject identifier based on the secevent subject identifiers and then solve rotation/identifier updating at that layer since it’s likely to be a common problem across all methods in which that RFC gets used. This would also serve as a decent encapsulation mechanism for DIDs/JWK thumbprints with the tradeoff that it’s introducing an abstraction point that could lead to new code paths in the future rather than keeping the identifier checks fairly constrained.