Directory Verifier

What a key directory is

An agent that signs its requests with Web Bot Auth publishes its public keys in one file on its own domain, at /.well-known/http-message-signatures-directory. A site that receives a signed request reads the address from the Signature-Agent header, fetches that file, finds the key and checks the signature against it. If the file is wrong, every signature that points at it is worth nothing, and the operator usually finds out only when requests start being refused.

This page checks the file itself. No signed request is needed, only the domain. To check a request your agent actually sent, use the Agent Verifier.

What is checked

• How the file is served. HTTPS, a 200 answer with no redirect, the media type application/http-message-signatures-directory+json, a size within limits, and caching headers.
• The keys. A real key set, usable Ed25519 keys, a kid equal to each key's thumbprint, no duplicates, no private key material, no test key from RFC 9421, and no expired key left in place.
• The proof that the file is yours. Whether the response is signed, with the directory tag, by every key it lists, over a content-digest of the body, and for at least as long as it asks to be cached.

How to read the result

Every check prints one line. A red line is a violation: a broken MUST of the draft, or private key material in the file. A yellow line is a deviation: a departure from a SHOULD, an entry this check cannot use, or a threshold of this check where the draft sets none. The data below the report names the keyword or the threshold behind each finding. Under each finding is the change that clears it. There is no grade: the standard has none, and a letter does not say what to fix.

The last line counts what passed, what deviates and what violates. Below it, the same report as data, with each key and what its own signature proved.

Faults worth checking first

• A kid that is a short label rather than the key thumbprint. The draft requires the thumbprint, and a verifier that looks keys up by it will not find yours.
• A response signed without covering the body. That proves the server holds a key and says nothing about the list of keys beside it.
• A proof that expires long before the cached copy does, so verifiers hold a key set whose proof has already lapsed.
• The file served as plain application/json, or behind a redirect between the apex and www. A verifier following the draft does not follow redirects, so the host your agents name has to answer directly.

The implementation guide shows how to publish a directory that passes every line, and how to sign its response.