No private key material

The published directory must contain only public keys. A private key component in any key is a serious leak.

What this check verifies

A Web Bot Auth directory exists so verifiers can read your public keys and check the signatures you send. For an Ed25519 key, the public key is three members: kty (OKP), crv (Ed25519), and x (the public key bytes, base64url).

The private key adds one more member, d: the secret scalar used to produce signatures. This check reads every key in the directory and fails if any of them contains a d.

A correct published key looks like this:

{ "kty": "OKP", "crv": "Ed25519", "x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo", "kid": "..." }

A leaked one carries the secret half as well:

{ "kty": "OKP", "crv": "Ed25519", "x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo", "d": "nWGxne_9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A", "kid": "..." }

Why it matters

The d value is your signing secret. Publishing it puts your private key on the open web, where anyone who fetches the directory can keep a copy. From that point on they can sign requests that verify against your own directory, which means they can impersonate your agent. You cannot un-publish a secret once it has been fetched, so the moment it goes up you have to assume it is compromised.

This is the most damaging problem the checker can find in a directory. That is why it overrides everything else: the grade is capped at F and the verdict is INVALID even if every other check passes.

How to fix it

  1. Treat the key as compromised. If d was ever served publicly, rotate it: generate a new keypair, publish the new public key, and stop using the exposed one. Removing the file is not enough, because the secret may already have been copied.
  2. Publish only the public key. Most libraries have a dedicated public export (for example, exporting the public JWK rather than the full key object). Use that instead of serializing the whole key.

The usual cause is serializing the entire key object straight from a generator. A freshly generated Ed25519 key holds both halves, so writing it to the directory as-is includes d. Export the public key explicitly and confirm the served JSON has no d member before publishing.

References

  • RFC 7517 defines the JSON Web Key format; d is a private key parameter.
  • RFC 8037 defines the OKP key type and Ed25519 for JOSE.
  • How grading works explains why a leaked private key caps the grade.

How the checker scores this

Tier
JWKS directory
Role
Authoritative. Failing this can lower the grade ceiling or change the verdict.
Grade cap
Failing caps the grade at F (Private key material present in published directory).
Verdict effect
Failing makes the verdict INVALID.
Point deduction
A failure deducts 25 points; a warning deducts 6.