Skip to content

Add JA4 request interface design spec - #469

Draft
dhruv8sh wants to merge 1 commit into
mainfrom
spec/283-ja4-request-interface
Draft

dhruv8sh wants to merge 1 commit into
mainfrom
spec/283-ja4-request-interface

Conversation

@dhruv8sh

Copy link
Copy Markdown
Collaborator

Summary

  • Adds the design spec for a provider-neutral JA4 TLS fingerprint interface (Expose JA4 through a standard request interface #283). Today the only route is the Fastly-only raw-request hook, where every app defines its own Ja4(String), and apps can't tell "this platform never supplies JA4" from "this request has none".
  • Proposes ctx.ja4() -> Option<&CapturedJa4>, backed by the adapter-owned RequestIngress metadata from Add pre-dispatch hooks and explicit request ingress fidelity #403. That metadata is inserted after the app's raw-request hook values, so app hooks can't overwrite it, and it is never derived from request headers.
  • Fastly (get_tls_ja4()) and Cloudflare (Bot Management ja4) populate it. Spin and Axum report NotExposed because they never see the TLS handshake. The spec also records the FoxIO research: only JA4 (BSD-3-Clause) is in scope; the other JA4+ methods are under the FoxIO License 1.1.

Spec only; no code changes. Implementation follows in a separate PR once the design is approved.

Changes

Crate / File Change
docs/superpowers/specs/2026-11-12-ja4-request-interface-design.md New design spec: requirements, FoxIO licensing and status, platform capabilities, alternatives, the edgezero_core::ja4 API and validation grammar, adapter insertion points, capability matrix, trust model, test matrix, docs plan, follow-ups (Axum/Spin via trusted proxy, EdgeZero-computed JA4), risks and decision log.

Closes

Refs #283. This PR intentionally does not close the issue; the implementation PR will.

Test plan

  • cargo test --workspace --all-targets (1550 passed)
  • cargo clippy --workspace --all-targets --all-features -- -D warnings (on the pinned Rust 1.98.1)
  • cargo fmt --all -- --check
  • cargo check --workspace --all-targets --features "fastly cloudflare spin"
  • WASM builds: wasm32-wasip1 (Fastly) / wasm32-wasip2 (Spin) / wasm32-unknown-unknown (Cloudflare)
  • examples/app-demo workspace: cd examples/app-demo && cargo test --workspace --all-targets
  • Docs build: cd docs && npm run lint && npm run format && npm run build
  • Manual testing via edgezero serve --adapter axum
  • Other: spec code references checked against origin/main and the pinned fastly 0.13.1 / worker 0.8.5 / spin-sdk 7.0.0 sources

Checklist

  • Changes follow CLAUDE.md conventions
  • No Tokio deps added to core or adapter crates
  • Route params use {id} syntax (not :id)
  • Types imported from edgezero_core (not http crate)
  • Store wiring goes through KvRegistry / ConfigRegistry / SecretRegistry (not the legacy single-handle setters) — see spec §6.6
  • New code has tests (spec only; the test matrix is in spec §10)
  • No secrets or credentials committed

Specify a provider-neutral JA4 accessor (ctx.ja4()) backed by adapter-owned
RequestIngress metadata: Fastly and Cloudflare populate it from their trusted
runtime APIs, Spin and Axum report NotExposed, and no adapter derives JA4 from
request headers.

Refs #283
@dhruv8sh dhruv8sh self-assigned this Nov 12, 2026
aram356 added a commit to IABTechLab/trusted-server that referenced this pull request Nov 12, 2026
Per the user, ID-7 relies on a trusted JA4 where the adapter supplies one
and otherwise does not block record creation (DEC-18), and JA4 is an
EdgeZero abstraction, ctx.ja4(), filled per adapter: Fastly from runtime
TLS, Cloudflare from Bot Management, Axum from a trusted proxy header such
as CloudFront's, Spin never. Trusted Server reads JA4 only through it, so
T12 deletes the direct Fastly read. IABTechLab/edgezero#469's draft leaves
Axum NotExposed and defers the trusted proxy header to its section 13.1;
the plan asks for that section in R2.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant