Audit Token Verification Bridge

ELI5

An audit token is a sealed envelope you can hand to a stranger. Inside is the list of what happened in a session, and stamped on the outside is the public seal that proves the envelope is real. The stranger can verify the seal alone — they never have to phone STRATT.

Technical Deep Dive

The route /audit/[token] is in the public-prefix list of middleware.ts, so it is reachable without a meridian session — that is the whole point: third parties verify without authenticating to STRATT.

Verification Sequence

sequenceDiagram
    autonumber
    participant V as Verifier (anyone)
    participant P as /audit/[token].astro
    participant O as orchestrator audit module
    V->>P: GET /audit/<token>
    P->>O: audit.verifyAuditToken(token)
    O->>O: parse envelope, extract pubkey
    O->>O: Ed25519 verify(payload, sig, pubkey)
    O->>O: check exp on envelope
    O-->>P: { valid, payload?, envelope?, reason? }
    alt valid
        P-->>V: render events list + exp + footer
    else invalid
        P-->>V: render reason (truncated/tampered/expired)
    end

Render Surface

The successful render shows:

• sessionId, issuedAt, event count, optional envelope.exp.
• One <li> per event with kind, actor, ts, optional justification, and the event’s strat URI plus blake3 content hash.
• A footer: “signed with Ed25519 … any third party can verify without contacting STRATT”.

The footer is doctrine, not decoration — it tells the reader why the page is publicly reachable without auth.

Failure Surface

result.valid === false renders reason verbatim inside <code>. Reasons surfaced by the orchestrator typically include truncated, bad_signature, expired, unknown. The page never explains which failure mode applies beyond the reason string — keeps the verifier unattackable by error-oracle probing.

Key Terms

• Envelope → Outer wrapper carrying pubkey, signature, exp; the payload is the inner events list.
• strat URI → Canonical reference into the STRATT unit graph (e.g. unit id at the time of the event).
• blake3 → Content hash of the artefact the event refers to; lets a verifier check that the artefact they have matches what was signed over.

Q&A

Q: Why include the public key in the token instead of fetching it from a JWKS? A: A JWKS lookup would force the verifier to contact STRATT, which defeats the “anyone can verify” promise. The signature still chains back to a known root because the public key’s kid matches the audit_keys table — anyone curious enough can cross-check, but it is not required for verification.

Q: Why is /audit/ allowed in the public prefix list? A: A third party verifier (auditor, regulator, counterparty) must reach the page without an airlock account. The verification logic itself is what gates trust, not the network boundary.

Q: What happens once envelope.exp is past? A: verifyAuditToken returns valid: false with reason="expired"; the page renders the failure section. The signature is still mathematically valid but the issuer chose to bound how long the link should be honoured.

Examples

Counsel emails a regulator a link https://stratt.dev/audit/<token>. The regulator opens it on their machine. Meridian renders 14 events, each tagged with the agent designation, justification quote, unit URI, and Blake3 hash of the artefact at that moment. The regulator pastes the artefact into a separate Blake3 hasher, confirms the hashes match, and signs off — without ever logging in.