- edited description
- changed title to document key selection algorithm
document key selection algorithm
Part of the discussion on today’s call about https://bitbucket.org/openid/fapi/issues/278/duplicate-kids-in-authorization-servers covered the fact that there is no documented key selection method (i.e. what fields of a key should a RP try and match to figure out which key to use to verify a signature).
There seem to be a willingness within the working group to try and document a key selection algorithm, and to potentially adding a clause to FAPI requiring/encouraging servers to ensure that only a single key is found when that selection algorithm is applied to an id_token and OP’s jwks.
Comments (14)
-
reporter -
there are two ways to do this:
1> the doc lists the key that is appropriate to the doc - that seems easiest, but apparently not commonly deployed.
2> the doc has a date (unix epoch time) that should be able to find the key that was used at the time the doc was signed. That is more robust if the OP can be be limited to one signing key at any one moment it time. That would entail creating guidance for the op to ensure that key roll-over was an exact science and that no ambiguities existed at roll over time (time skew is a big one, but queueing is another) I would suggest asking the CA/B forum for guidance on this if it is chosen
-
reporter For the record, here’s all the clauses in the various openid specs that I’m currently aware of mentioning things related to key selection:
https://openid.net/specs/openid-connect-core-1_0.html#Signing
If there are multiple keys in the referenced JWK Set document, a
kid
value MUST be provided in the JOSE Header.
https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys
The signer publishes its keys in a JWK Set at its
jwks_uri
location and includes thekid
of 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 thejwks_uri
location. The signer can begin using a new key at its discretion and signals the change to the verifier using thekid
value. The verifier knows to go back to thejwks_uri
location to re-retrieve the keys when it sees an unfamiliarkid
value. The JWK Set document at thejwks_uri
SHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a smooth transition.
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
When both signing and encryption keys are made available, a use (Key Use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage.
-
Put it in the security consideration in ver. 1.0.
For 2.0, we should determine where we should put it.
-
- changed status to open
-
-
assigned issue to
-
assigned issue to
-
Issue
#278was marked as a duplicate of this issue. -
@Joseph Heenan looking at the OIDC issue - it seems that OIDC is going to add an errata to prohibit duplicate kids? Do we still need this?
-
reporter https://bitbucket.org/openid/connect/issues/1127 was closed without any errata being issued unfortunately.
So we still have the original problem - there’s no interoperable defined mechanism for how RPs should select the key to be used to verify a signature.
-
-
- changed status to resolved
pr merged
-
- changed component to Part 2: Advanced
-
- changed component to FAPI 1 – Part 2: Advanced
-
- changed component to FAPI 1: Advanced
- Log in to comment