duplicate kids in authorization server's jwks
[I’d previous sent an email to the WG list, but on the 5th Feb WG call, Nat asked me to open this as a ticket so it can be properly tracked.]
I wanted to direct the FAPI working group to this discussion within the Connect working group:
https://bitbucket.org/openid/connect/issues/1127
Namely that duplicate kids are not permitted in JWKS.
A test for this was recently added to all the conformance tests, which caused one of the UK banks to opine:
it is valid for the JWK endpoint to return multiple KID instances, one for each ‘alg’ supported?
The spec calls for the alg PS256 or longer to be supported, so we also have (for instance) PS384, PS512. And although we may show a couple that we don’t need, my point is that it must be valid to show multiple key entries to support multiple valid alg values.
To some extent this seems a reasonable point, reusing a key across across two algs that can use the same key seems ok, and arguably perhaps better than having the key once without an ‘alg’ specified.
As this affects the FAPI certification tests, I wanted to check the FAPI WG agrees with the decision in https://bitbucket.org/openid/connect/issues/1127 - any opinions (positive & negative) would be great please.
Comments (10)
-
reporter -
reporter - changed title to duplicate kids in authorization server's jwks
-
The Australian CDR Register is keying off
kid
in order for Data Recipients to establish Access Token’s to consume Register APIs. Duplicatekid
's would likely have unintended consequences.
-
- Document the key selection algorithm when duplicated
kid
is present. - FAPI certification should give a “pass” to duplicated kids.
- One example: https://bitbucket.org/b_c/jose4j/src/master/src/main/java/org/jose4j/jwk/VerificationJwkSelector.java
- Nimbus has a similar pattern.
- Document the key selection algorithm when duplicated
-
- changed status to open
Add key selection documentation.
-
reporter I’ve opened https://bitbucket.org/openid/fapi/issues/279/key-selection-algorithm to cover the key selection part.
The duplicate kid part was discussed on today’s call. There was a strong consensus on the call that the FAPI certification tests should not test a behaviour unless it is required by the FAPI standard (or from a normative reference I presume), and as there does not appear to be such a clause the test should be removed or made a warning. There are definitely some interoperability concerns around duplicate keys, but the best approach seemed to be to remove this particular test for now, and implement a new test once we have a document key selection algorithm.
-
- changed status to duplicate
Duplicate of
#279. -
- changed component to Part 2: Advanced
-
- changed component to FAPI 1 – Part 2: Advanced
-
- changed component to FAPI 1: Advanced
- Log in to comment
Link to email thread: http://lists.openid.net/pipermail/openid-specs-fapi/2020-January/001655.html