Test modeDemo environment — no real identity data is processed

Innom console · 04

Planes

Live inspector for the acceptance and attestation planes: what each learns, the blinded exchange, and the transcript digest question.

The two planes

Acceptance plane

0 in retained log

Knows the relying party, never the user.

Knows

  • Which relying party asked, and under which signed policy pack (id and hash)
  • The ceremony's state machine: every transition, outcome and evidence record
  • That a valid attestation occurred against this ceremony's nonce
  • The attestation's method class, assurance level and opaque transcript digest
  • A subject seed derived under the attestation plane's pepper — which this plane cannot invert (it does not hold that pepper)

Does not know

  • Who the user is — no name, no date of birth, no document ever reaches this plane
  • The commitment itself: it receives only the HMAC-derived seed, and cannot reverse it without the attestation pepper
  • The proof or the credential — they never leave the attestation plane
  • How to link the same holder across two relying parties: each token's subject is derived per-RP

Route groups

  • POST /api/v1/ceremonies
  • GET|PATCH /api/v1/ceremonies/{id}
  • POST /api/v1/tokens
  • POST /api/v1/tokens/verify

Attestation plane

0 in retained log

Knows the method, never the destination.

Knows

  • That a Groth16 proof verified against the commitment in the issuer's signed credential
  • The method class the credential implies (M0 reusable, M1 wallet) and the assurance it supports
  • The challenge ticket's claims: threshold, date, one-time nonce, circuit identity and the policy pack hash
  • Which issuer signed the presented credential

Does not know

  • Which relying party the verification is for — the strict request schema refuses an rp_id, and adding one is a parse failure by design
  • Which ceremony the proof belongs to — no ceremony identifier crosses this boundary, so a rejected attestation cannot be tied to a gate
  • The date of birth: the proof authenticates the age predicate without revealing dob_days, which never leaves the wallet origin
  • Whether the verification ever resulted in a token — the outcome is decided on the acceptance plane

Route groups

  • POST /api/v1/attest/zk
  • POST /api/v1/credentials

The blinded exchange

Every ceremony crosses both planes exactly three times. The ceremony nonce is the only thread that joins them; each plane holds its own signing keys and its own pepper, and the config refuses to boot if the two peppers ever match.

  1. 1 · Open/api/v1/ceremoniesRelying party's page → acceptance plane

    Carries

    • publishable key
    • jurisdiction
    • category predicate
    • device capabilities

    Never receives

    • anything about the user — there is no user in this request

    The publishable key identifies the relying party — no separate rp_id is sent. The acceptance plane resolves the signed policy pack from it and returns the method plan with a one-time zkChallenge.

  2. 2 · Prove/api/v1/attest/zkWallet on the user's device → attestation plane

    Carries

    • challenge ticket
    • issuer-signed credential
    • Groth16 proof
    • public signals

    Never receives

    • rp_id
    • ceremony id
    • date of birth

    The attestation plane verifies the proof against the credential's commitment and derives a subject seed under its own pepper. It never learns where the verification is going.

  3. 3 · Join/api/v1/tokensRelying party's page → acceptance plane

    Carries

    • ceremony id
    • signed attestation

    Never receives

    • the commitment
    • the proof
    • the credential

    The ceremony nonce is the only thread joining the planes. The acceptance plane mints a per-RP pairwise subject from the seed and files the opaque transcript digest as evidence.

The transcript_hash question

The evidence vault's acceptance-plane records carry a transcript_hash. If the gateway never learns the transcript, what is it storing?

An opaque digest. transcript_hash is a SHA-256 hash over the attestation decision's inputs — the circuit identity, verification-key hash, public signals, proof hash, credential issuer, credential id, policy pack hash and method class. The gateway stores the digest and never the inputs; it cannot invert the hash to recover them.

An auditor who independently holds the same inputs can recompute the hash and confirm the record describes the decision it claims to. That is the design intent: auditable without surveillance.

One field is disclosed deliberately: method_class (M0, M1, …). Policy packs and regulators require method-level reporting, so the class of method used is part of the record — but nothing about the holder is.

Live plane request log

Live — real requests recorded by this deployment

The log records the ceremony-forming POSTs across both route groups. Per-request state polling (GET and PATCH on a ceremony) is not listed, so the exchange stays legible. Every listed entry is real — recorded by this gateway process as the request arrived. Nothing here is synthesised.

No requests logged yet.

This deployment has not received any ceremony-forming requests since it started, so there is nothing to list. This page fabricates nothing: entries appear only when real requests hit the gateway — drive a ceremony on either site and reload to see the exchange appear here.

0 requests recorded in total · newest 0 retained