Ed25519 signature verifies

What this check verifies

This is the check the whole signature tier builds toward: the cryptographic verification. Web Bot Auth signs with Ed25519 (RFC 8037). The verifier reconstructs the RFC 9421 signature base from the covered components and the @signature-params line, then checks the signature bytes against that base using the resolved directory public key.

The signature base is rebuilt exactly as the signer built it: one line per covered component, then the @signature-params line. For the web-bot-auth profile, @authority is derived from the request Host:

"@authority": example.com
"@signature-params": ("@authority");created=1717603200;expires=1717606800;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0";tag="web-bot-auth"

The signature bytes come from the Signature header and the public key from the directory key that keyid resolved to. If Ed25519 verification succeeds, the request was signed by the holder of that key over exactly this base. If it fails, the check fails.

Why it matters

This is the step that actually proves the request came from the agent it claims to be. Every other check confirms the signature is well-formed and current; this one confirms it is genuine. A signature that does not verify means the bytes do not match the key, the covered content, or both. The request cannot be trusted as coming from the named agent.

Because this is the cryptographic core, a failure here is decisive. It caps the grade and makes the signature verdict invalid, regardless of how clean the rest of the headers are. A well-formed signature that does not verify is still a signature that does not verify.

How to fix it

A verification failure with a correctly resolved key almost always comes from a mismatch between what was signed and what the verifier reconstructs:

1. Sign and reconstruct over the same covered components. The list in Signature-Input must match the components actually fed into the signing base, in the same order.
2. Match the @authority value to the request Host. The signer derives @authority from the host it is sending to; if the request reaches the verifier with a different Host (a proxy rewrite, a port difference), the base differs and verification fails.
3. Sign and verify against the same key. The private key used to sign must be the pair of the public key published under the resolving keyid. A rotated or mismatched key breaks this even when everything else lines up.
4. Do not alter the signed parameters after signing. Changing created, expires, keyid, or tag after the signature is made changes the @signature-params line and invalidates the signature.

Use a profile-aware library on both ends so the signature base is constructed identically. Hand-built bases are the usual source of an otherwise inexplicable failure.

References

• RFC 9421 defines the signature base and the verification procedure.
• RFC 8037 defines Ed25519 (the EdDSA algorithm and OKP key type) for JOSE.
• keyid resolves to a key covers how the public key is selected from the directory.
• How grading works explains why a verification failure caps the grade and makes the verdict invalid.