feat: the ceremony circuits — two-commitment bearer link, digest-bound Google

[SupremaLex]

Brings the circuits in line with the merged ceremony specification. The
requirements behind every change landed in #10 and #11, so nothing here rests
on an open or closed spec PR.

bearer-link — new, and it serves both X and GitHub

REQ-PLAT-32B and REQ-PLAT-52A give X and GitHub byte-identical statements, so
one circuit serves both and the Verifier Governance Process registers it once
per profile. That is the exact artifact per profile REQ-PLAT-01A asks for, not
a different one.

It proves exactly one thing: one hidden bearer opens both attestations'
blinded commitments. Two public inputs, nothing else. No authorization
digest, client identifier, timestamp, endpoint, userId or handle — the
Platform Verifier reads each of those from revealed attestation bytes or binds
it by recomputing the PKCE verifier, and a fact checkable in the open does not
belong in a proof.

Why a circuit is needed at all: the two sessions draw independent blinders
(REQ-COMMON-44), so the same bearer commits to two different values and nothing
on chain can tell they open to one credential.

	gates
the X circuit this replaces	76,618
bearer-link	42,008

It is cheaper than what it replaces. Dropping the keccak nullifier more than
pays for the new printable-ASCII charset constraint; replay is now the
Authorization Digest the Consumer records under REQ-COMMON-03A.

The bearer bound is 128, not the 4096 REQ-PLAT-30 permits

Measured before choosing:

MAX_BEARER_LEN	gates	native prove
128	42,008	0.9 s
512	104,752
2048	355,728
4096	690,362	11.0 s

4096 pads to 2^20 and uses two thirds of it; browser bb.js runs several times
slower than native, so it is tens of seconds on desktop and a real risk on
mobile. 128 is what the deployed X circuit has always enforced and what live X
ceremonies produce; GitHub gho_ tokens are 40 bytes. The bound is one
constant and a verifier regeneration, and 256 would cost 62,922 gates — still
below today's baseline — if more headroom is wanted later.

The charset constraint itself is nearly free: about one gate per byte.

jwt_email — Google bound to the Authorization Digest

Public inputs become exactly the six of REQ-PLAT-16B, in its order. The
62-byte free-text nonce becomes the 32-byte digest; the chain_id and
registry_addr pass-throughs go, because the digest already commits the chain,
the operation and the verifier version.

The circuit encodes rather than decodes: it re-encodes the digest to
base64url and compares against the signed payload. Both bind the same pair,
encoding is the cheaper direction, and the fixed 43-character length leaves no
room to witness a longer nonce and hide bytes in it.

It reproduces the pair the specification publishes:

b318fb55…4c0af5  →  sxj7VZ4WoXm4U-0oU1ds2hYDLZOwg5u4GlUTXTNMCvU   (§3.1)

178,899 gates, against 179,189 before.

The nonce encoder is noir_base64, not hand-rolled

The library was already a dependency here, and BASE64_URL_ENCODER is the
URL-safe unpadded variant whose length formula gives exactly 43 for 32 bytes.
It costs 468 gates more than the hand-written version — 0.26 % — and is worth
it to not own a base64 implementation.

Its tests check it against Python, an oracle outside the Noir ecosystem,
not only against the spec vector. The all-ones digest is the sharp case: it
ends in 8, not _, because a two-byte tail forces the final character's low
two bits to zero. An encoder emitting a fourth tail character or padding fails
there. Verified by swapping in the standard alphabet, which turns two tests
red.

Contract sizes are unaffected — worth knowing

A 16× smaller circuit with 1/68th the public inputs produces a verifier one
byte larger:

verifier	runtime bytes	vs EIP-170
BearerLinkHonkVerifier (42k gates, 2 inputs)	27,699	−3,123
HonkVerifier (Google, reworked)	27,697	−3,121
XHonkVerifier (old, 76k gates, 5 inputs)	27,698	−3,122

The Honk verifier is fixed-size; only N and LOG_N change. So the size work
and the circuit work are independent, and waiting for one before the other buys
nothing. Public inputs do drop 136 → 64, which cuts calldata and verification
gas.

Notes

• dyaka-noir-token is left in place and still building. bearer-link
  replaces it, but the live X demo still uses it; it should go at cutover.
• Gate counts were recorded for the first time doing this — no repo carried one
  before.
• jwt_email's vk_hash changes, so its Solidity verifier regenerates with it.

Verification

nargo fmt --check, nargo test and scripts/build.sh all pass for every
circuit: 12 tests for bearer-link, 3 for jwt_email, 9 unchanged for
dyaka-noir-token.

bearer-link  vk_hash 02bbc194f5160b0918f408d0f67445b8882e86d76e58b3465637cb6bcb26818e
jwt_email    vk_hash 24db903f725957f760b865b2c6f010da37d7c9397b800c21113fbd0388a5a69f

[xgreenx]

Approving on the strength of an independent verification run under the pinned toolchain (nargo 1.0.0-beta.20, bb 5.0.0-nightly.20260324): all 24 tests pass, both vk_hashes reproduce byte-for-byte (02bbc194…818e, 24db903f…a69f), all three gate counts reproduce exactly, every embedded vector re-derives independently in Python (including the spec §3.1 digest→nonce pair), and adversarial probes against the commitment scheme (preimage re-splitting across the bearer/blinder boundary, length edges at 128/129) all fail the way they must. bearer-link's two-input shape is not just acceptable but mandated — REQ-COMMON-02B forbids a digest input on PKCE profiles.

Two findings worth a follow-up commit — both pre-existing on main (this PR doesn't introduce them), both defense-in-depth misses rather than live attacks, since exploiting either needs Google to emit non-canonical/unescaped JSON:

1. Missing trailing-structural-byte check on the five string claims — circuits/jwt_email/src/main.nr:128 (email), :148 (nonce), :167 (sub), :217 (iss), :232 (aud). REQ-COMMON-19 (invoked for these claims by REQ-PLAT-21) requires asserting the closing quote and the following structural byte (, or }); today only email_verified and exp do. Without it, a claim-shaped substring inside another signed string value would match — JSON escaping of attacker-typed content is what currently prevents that.

2. exp accepts leading zeros — circuits/jwt_email/src/main.nr:189-203. REQ-COMMON-19D demands canonical 0|[1-9][0-9]* and explicitly lists leading-zero among the rejects; the circuit accepts any digit run. Non-exploitable with signature-fixed bytes from an honest issuer, but it's a written MUST.

PS: the PR body's 178,899 gate figure for jwt_email is the pre-noir_base64 number; the branch as it stands measures 179,367 (matching the third commit's message).