cnf and key rotation
alenhorvat opened this issue · comments
Hi.
DIDs, allow key rotation. Use case: legal entities/organisations/companies
https://www.rfc-editor.org/rfc/rfc7800
says:
By including a "cnf" (confirmation) claim in a JWT, the issuer of the
JWT declares that the presenter possesses a particular key and that
the recipient can cryptographically confirm that the presenter has
possession of that key. The value of the "cnf" claim is a JSON
object and the members of that object identify the proof-of-
possession key.
kid can be a DID, which is legal according to the rfc7800 (The content of the "kid" value is application specific.)
issuer of the JWT declares that the presenter possesses a particular key
Can the holder (legal entity) present the credential with a different key from the one defined in the cnf? E.g., legal entity is rotating keys every year.
IMO, it is probably a decision of the issuer to include a DID URI for the kid and therefore allow the Holder to change the authoritative key. So, I guess this might be possible with the current language, although it is not RECOMMENDED since we have this requirement for cnf in 4.2.2.2 Registered JWT Claims ...
It SHOULD contain a JWK
Does this clarify the question? Is there anything you want us to change in the current spec?
Yes, but this essentially blocks key rotation. For Natural Persons that's not an issue, but it becomes an issue for Legal Entities.
If "SHOULD" -> "MAY" would be better since we don't want that capabilities are limited by the data model.
Would you be ok to change "SHOULD" to "RECOMMEND". We only want that JWK is the default mechanism. We don't want to prevent other mechanisms. We will add a informative sentence that describes that other cnf methods are also allowed. Would you be ok with that?
Hi @awoie . Yes.
You plan to keep the requirement for the endpoint (.well-known) or (.well-known) is default you recommend, but other endpoints are possible?
Relates #168 that will explain different means of issuer key discovery and DIDs will become one informative option. We will also changed SHOULD to RECOMMEND to address this issue.