Architecture

EdSSA’s hot path is a single function: verify_token(&[u8; N], &ActiveEdssaState<N>). Everything else is plumbing around keeping the state fresh and the verifier honest.

FIG. 1 — Overall system architecture

📌 Figure pending publication. FIG. 1 is part of the A1-publication-ready patent application; it will land here alongside the public migration step that drops the figures into docs-site/src/figures/fig-1-architecture.png.

The system is three layers:

1. Client. Mints a token from (seed, sub_id, claim_state) and stamps X-EdSSA-Token: <fleet_id>-<token> on every outbound request.
2. Verifier (edssa-server-ce). Sits as a sidecar; on each inbound request it loads the fleet’s ActiveEdssaState via a wait-free ArcSwap and performs the O(N) match.
3. Backend. Receives forwarded traffic with the X-EdSSA-Token header stripped (Zero-Trust edge separation — the credential never crosses the verify-to-app boundary).

FIG. 2 — Credential construction

📌 Figure pending publication. FIG. 2 will land at docs-site/src/figures/fig-2-construction.png.

Token construction:

1. The client knows the fleet’s seed and picks a sub-ID for the request.
2. For each slot i ∈ [chaff_count, N − SUB_ID_SLOTS), the client derives the secret byte:
   • CE first cut: wire_byte(SHA-256(seed ‖ i_le)[0]).
   • Enterprise (with the ratchet running): the ratchet’s cell at position i is hashed forward on a clock-driven cadence; the verifier publishes the new ActiveEdssaState atomically.
3. Chaff slots [0, chaff_count) carry random bytes the verifier ignores.
4. Sub-ID slots [N − SUB_ID_SLOTS, N) carry the ASCII-hex encoding of the sub-ID (encode_sub_id).

Verification mirrors the construction step-for-step. Bytes at chaff positions don’t contribute to the match count; the match count must reach threshold_T for the token to be accepted.

FIG. 3 — Synchronisation and tolerance windowing

📌 Figure pending publication. FIG. 3 will land at docs-site/src/figures/fig-3-synchronisation.png.

The Enterprise build’s drift corrector (F-16) gates ratchet advancement on a median-of-3 over independent time-anchoring oracles. CE pins the verifier state at boot and does not run a ratchet, so this figure is purely informational for CE operators.

Plasticity presets (ADR-008)

CE pins N = 64 and accepts all three presets. Operators can override chaff_C / threshold_T per-fleet if the preset doesn’t fit; width_N is the only field CE refuses to deviate from.

Wire format

Header: X-EdSSA-Token: <fleet_id>-<token>.

ADR-004 documents why the parser splits at the last dash (token bytes never contain -, so the fleet-token boundary is unambiguous).

What changes in Enterprise