feat: validate directories from verification page

[MukundaKatta]

Fixes #37.

Adds a Worker-backed directory validator to the verification website:

• exposes /v0/api/validate-directory?url=... so the Worker fetches directory URLs server-side
• validates that the URL is HTTPS and points at /.well-known/http-message-signatures-directory
• checks that the response is JSON with a non-empty keys array and purpose string
• adds a small form to the verification page so users can paste a directory URL and get browser feedback
• covers validation error paths in the Worker test suite

Validation:

• npm ci
• npm run build
• npm run test -w verification-workers -- --run --reporter verbose

[AkshatM]

Thanks for the PR! It's in good shape, but needs broadening to support #37 unfortunately. I've left some comments accordingly.

[AkshatM]

validateDirectory and validDirectoryURL are validating something different than what #37 is expecting, alas.

To be a valid directory, it should implement all the checks the http-signature-directory crate is doing today. There are some critical missing ones today:

1. Content-Type header matches what's expected
2. It should parse Signature-Input and Signature headers appropriately, then check if performing a WBA verification against Signature passes for every key listed in the key set returned by the directory. This can be accomplished using the existing Typescript packages.
3. It should ensure Signature-Input contains the right components, specifically @authority and the right tag.
4. It should verify that the Signature isn't expired.

The reference crate only supports Ed25519, but the Typescript packages in this repository support multiple. You should utilise it to implement what you need.

[AkshatM]

I don't think purpose is required by the JSON web key set format described in the RFC for signature directories, so you can drop this check.

[MukundaKatta]

Thanks @AkshatM. Two follow-ups:

• I'll re-read the http-signature-directory crate and rewrite validateDirectory to enforce the same checks (signature verification on the JWKS, controlled-by URI matching, etc.) so the worker example matches what Verification website should be able to validate directory #37 expects.
• Will drop the purpose check in the next push.

Let me know if you'd prefer this scoped here or split into a follow-up PR — happy to do either.

[AkshatM]

Let me know if you'd prefer this scoped here or split into a follow-up PR — happy to do either.

Scoped here is sufficient.

[thibmeu]

thanks for the PR @MukundaKatta

i worry about the introduced DoS vector this introduces, by allowing a proxy to fetch arbitrary URLs. Specifically, the tricky part is fetching arbitrary URLs, mentioned #37 (comment), which this is essentially proposing

having a simpler design requesting a captcha pass (like turnstile) and light validation on the proxying side, while the browsre performes the actual check

maybe so we can tune the design: is your use case local validation in a browser, an API that you can hit, something else?

[thibmeu]

this is an arbitrary fetch, which creates a DoS vector

[MukundaKatta]

Pushed f21486b addressing all four points from the review:

1. Content-Type check — now enforces application/http-message-signatures-directory+json per the reference Rust crate. Mismatch returns 502 with a clear error.
2. Cryptographic verification — switched from "shape only" validation to running verify() from web-bot-auth against the response, looping over every key in the JWKS. The library handles tag (web-bot-auth) + signature freshness (created/expires) automatically. A failure on any listed key surfaces as keys[N]: <reason> so the report is per-key.
3. @authority;req support — request side is provided as a ResponseRequestPair so the verifier can resolve @authority with the req parameter from the request that fetched the directory.
4. DoS vector — capped the response body at 64 KB before parsing JSON. Larger payloads return 502 with a clear error.

Also dropped the purpose check.

Multi-kty: gated behind kty === "OKP" (Ed25519 only today, matching the reference crate); non-Ed25519 fails with unsupported kty "<value>" rather than silently importing under the wrong algorithm. Happy to add RSA/EC import as a follow-up if you'd like — wanted to keep this PR scoped to the alignment with the reference behavior.

The pre-existing tsc error at verifySignature (line 359 in original) for await verify(request, ...) is untouched — it's the workers Request vs ResponseRequestPair mismatch that exists on main too. Happy to fix in this PR or split it out, your call.