Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Introduction

Availability today

The Community Edition — edssa-server-ce, the self-hosted verifier binary — is not publicly distributed yet. Two consequences, both of which you will hit as concrete errors rather than as a notice:

  • The repository is private. github.com/edssa-io/edssa is not public, so git clone fails with a permission error unless your account has been granted access. Access is arranged per customer, because the code is BSL 1.1 and part of it is under a patent filing hold — write to support@edssa.io.
  • The CE image is not on Docker Hub. edssa/server-ce:1.0.0 is referenced throughout the samples but has not been pushed, so docker pull fails with pull access denied. Publishing is operator-side, after the public migration of v1.0.0-ce. Every command in these docs runs against an image you build locally from the source tree, so none of them needs the registry.

Autopliance, the hosted product, is live and needs none of the above — no source access, no image, no self-hosting. If you want verified traffic and compliance reports today, that is the path that is open: see Autopliance — getting started.

EdSSA is a zero-trust, post-quantum, stateless M2M authentication engine. The Community Edition (CE) ships as a single binary, edssa-server-ce, that sits as a sidecar in front of any HTTP service and refuses inbound traffic that doesn’t carry a valid X-EdSSA-Token.

What problem does it solve?

Most service-to-service authentication today is “send a bearer token in a header”. The token is a long-lived shared secret:

  • If it leaks (logs, env files, exception traces), it remains valid until rotated.
  • It can be replayed indefinitely by any party that observes one valid request.
  • It binds no information about the caller’s environment, identity, or per-request claim.
A bearer token is replayable once observed; an EdSSA token is derived per request, so an observed one is already spent. SHARED SECRET IN A HEADER client service sk_live_a3f… observed once — in a log, a trace, an env file the same bytes work again, and keep working until someone rotates it DERIVED FROM SHARED STATE client verifier token @ tick n both sides already hold the seed — it is never the thing on the wire observed at tick n, presented at n+1: refused — that token is already spent
The shape of the change. A bearer token is a secret you send, so observing one is enough to reuse it. An EdSSA token is derived from state both sides already hold, so what crosses the wire is evidence of the secret rather than the secret itself — and it stops being accepted as the ratchet advances.

EdSSA replaces “send a secret” with “derive a per-request verifier from shared state”. The token on the wire is a fixed- width, wire-safe byte sequence whose content depends on:

  1. A long-lived seed shared between client and server.
  2. A per-request sub-identifier the client claims in the token itself (so the verifier knows which sub-fleet / sub-tenant to consult).
  3. Chaff slots that contain random bytes the verifier ignores (so observed tokens don’t reveal the secret layout).

The verifier performs an O(N) byte comparison with no heap allocations, no locks, no async calls, and no network hops. On the Phase-0 microbench at N=64 the verify call is ~22 ns — within the budget of even the most aggressive operator-grade deployment.

What’s in the Community Edition?

edssa-server-ce sits in front of an unchanged HTTP service and refuses traffic that carries no valid token. inbound HTTP edssa-server-ce one binary, sits as a sidecar checks X-EdSSA-Token on every request valid your HTTP service unchanged — it never sees a token missing / stale / forged refused at the edge No network hop, no heap allocation, no lock — the verifier compares bytes it already holds.
Where CE sits. The binary is a sidecar in front of a service you do not modify: traffic carrying a valid token passes through untouched, and everything else stops at the edge.

CE is a strict subset of the Enterprise build (see CE feature subset):

  • One fleet per binary.
  • Token width pinned at 64 bytes.
  • Audit tiers 0–2 (silent / errors / result).
  • No multi-fleet routing, no swarm, no payload channel, no Tier-3 response-chain replay defence, no Tier-4 Merkle audit.

Held-back paths refuse to validate at boot rather than running in a degraded mode. Operators who need them upgrade to the Enterprise build.

License

CE ships under the Business Source License 1.1 with Apache-2.0 as the Change License after 4 years per file. Additional Use Grant: “non-commercial OR commercial ≤ $1M ARR”. An explicit non-revocable patent grant covers permitted use.

The executed LICENSE, PATENTS and NOTICE files ship at the root of every distribution, which is the authoritative copy. (The decision record behind the policy lives in the source repository, which is not public — so it is named here rather than linked, to save you a 404.)

What it looks like running

The EdSSA operator panel's live dashboard: 36 verifications per second, a 100% accept rate, health with three of three oracle sources, p50/p95/p99 latency in microseconds, a reject-reasons breakdown reading zero across every reason, and per-fleet ratchet and shuffle rates.
The operator panel reading live counters off a running verifier — verification rate, accept rate, latency percentiles, why anything was rejected, and the ratchet advancing per fleet. Captured against the local pilot stack (samples/real-local) driving synthetic traffic across three fleets, so every number here is measured rather than mocked. The panel is an Enterprise surface: CE is the verifying binary alone, with no console.

The reject-reasons card reading zero is the ordinary case, and the reason it is on the dashboard at all is the interesting one: each counter names a distinct way a credential can fail — the bytes not matching, a replay the Bloom filter caught, a sequence outside the window, an unknown fleet — so when something does break, the panel says which, rather than only that the number went down.

Where to next?

  • Want the hosted product rather than the binary? Start with Autopliance — sign up, drive a fleet, generate a report.
  • New to EdSSA itself? Start with Quickstart.
  • Operator standing up CE in production? Read the Operator runbook.
  • Wondering what the patent covers? See Patent advisory.