No duplicate key ids

No two keys in the directory may share the same kid value.

What this check verifies

This check collects the kid value of every key that has one and confirms they are all distinct. If two or more keys carry the same kid, the check fails. Keys without a kid are not counted here.

At the well-known path a kid, when present, is the key’s RFC 7638 thumbprint (see Key id and thumbprint). Two different keys have different thumbprints, so a key set with two keys has two distinct kid values:

{
  "keys": [
    { "kty": "OKP", "crv": "Ed25519", "x": "<public key A>", "kid": "<thumbprint of key A>" },
    { "kty": "OKP", "crv": "Ed25519", "x": "<public key B>", "kid": "<thumbprint of key B>" }
  ]
}

Why it matters

The kid identifies a key. A verifier following the protocol draft can select a key by matching the signature’s keyid against kid. When two keys share a kid, the value no longer points to a single key, so such a lookup cannot tell which one is meant. This is mainly a sign of a copy-paste error during key rotation, where a new key was added but its kid was left as a copy of the old one. The same mistake often leaves the public key (x) wrong too, so a duplicate kid is worth investigating beyond the label itself.

This checker resolves an incoming signature by computing thumbprints, so a duplicate kid does not break resolution here. Verifiers that look keys up by kid can pick the wrong key, and the duplicate usually points to a mistake in the key set, so the checker fails it.

How to fix it

  1. Set each key’s kid to its own thumbprint, or remove kid.
  2. Check that the duplicate is not a sign of a key that was copied wholesale: confirm each key’s x is the correct, distinct public key, not a copy of another.
  3. If a key was meant to be removed during rotation, remove it rather than leaving a second copy with the same label.

The usual cause is rotating keys by copying an existing key block and forgetting to update its kid (and often its x). After the fix, each kid in the set is unique.

References

  • RFC 7517 defines kid as a key identifier within a key set.
  • The Web Bot Auth protocol draft (draft-ietf-webbotauth-httpsig-protocol-00), section 5.5, requires a kid at the well-known path to be the key thumbprint.
  • How grading works explains how directory checks contribute to the grade.

How the checker scores this

Tier
JWKS directory
Role
Advisory. Failing this never caps the grade or changes the verdict.
Point deduction
A failure deducts 25 points; a warning deducts 6.