document key selection algorithm

[Joseph Heenan]

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.

[Tom Jones]

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

[Joseph Heenan]

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 the kid 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 the jwks_uri location. The signer can begin using a new key at its discretion and signals the change to the verifier using the kid value. The verifier knows to go back to the jwks_uri location to re-retrieve the keys when it sees an unfamiliarkid value. The JWK Set document at the jwks_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.

‌

[Nat Sakimura]

Put it in the security consideration in ver. 1.0.

For 2.0, we should determine where we should put it.

[Nat Sakimura]

Issue #278 was marked as a duplicate of this issue.

[Dave Tonge]

@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?

[Joseph Heenan]

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.

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/167/add-duplicate-kid-key-selection-alg

[Dave Tonge]

pr merged