docs(specs): identity digests and disclosure for the Google profile

[SupremaLex]

A private mode for Gmail handles. The Google profile's Proving Circuit exposes the handle and the canonical userId as keccak256 digests instead of bytes, and the Consumer keys the binding on those digests. The plaintext reaches the chain only in a transaction that discloses it: a claim whose authorized operation says so, or a later disclosure call from the owner. Whoever knows an address still resolves it; nobody reads it off the chain.

The design note (design/private-gmail-handle.md) holds the rationale, the options considered, the measured circuit cost, and every decision taken. The rest is the specification text it graduates into, followed by the review fixes.

The specification

specs/platform-ceremonies.md

• §2.1a's lead-in and REQ-PLAT-08A/08B admit a circuit that normalizes what it digests, refusing where the vector table trims, and a Consumer that keys on digests and normalizes every handle it receives.
• A new §2.1b defines disclosure (history: once any transaction has carried the plaintext) and publication (Consumer state), with these requirements:
  • REQ-PLAT-08D: keys come from the digests. The disclosure choice sits in the claim's Authorized Transaction Data. Plaintext is accepted only when authorized and only when it hashes to the digests, both or neither. A bytes profile always discloses. A private claim keeps the published name when it re-proves the same handle, and clears it otherwise.
  • 08E: the disclosure call publishes. It requires the identity and handle keys to be each other's current pair, in both directions, and the caller to own both.
  • 08F: the event carries a disclosed flag and the normalized handle.
  • 08G: the Consumer holds a digest platform's handle rules fixed once it has bound anything.
  • TEST-PLAT-20A exercises all of them.
• REQ-PLAT-03: the Canonical Runtime releases the plaintext to the application only for a disclosing claim.
• REQ-PLAT-04 and 16D: a backslash in sub is refused, so nothing the circuit digests holds an escaped byte.
• REQ-PLAT-16B/16C/16D: the digests become public inputs, the Platform Verifier returns them and passes plaintext through unchecked, and the sub/email validation moves into the circuit, with 31- and 62-byte buffers. TEST-PLAT-06A exercises them.
• §9 states what the digests protect and what they do not.
• The Google profile stays Platform Ceremony Version 1. Nothing is released, so its statement is edited in place.

specs/ceremony-common.md

• ASM-HASH-01 (preimage resistance, with the enumeration caveat) and ASM-ZK-01 (a zero-knowledge proof system).
• SP-PRIV-01: plaintext reaches the chain only in a transaction that discloses it. That transaction publishes it when sent, accepted or not.
• REQ-COMMON-05E returns the digests, and any plaintext marked unverified, which the Consumer trusts only once it hashes to them.
• REQ-COMMON-45 selects only zero-knowledge artifacts for a digest profile.
• §12 replaces "published deliberately" for the handle and user identifier with the digest profile's confidentiality and its limits.

specs/libid.md: one sentence among the enforceable guarantees.

Decisions carried

• What private means: hidden but resolvable by the exact address, not a salted commitment. sub is hidden with the handle.
• Who chooses: the user, not the application. disclose joins the claim's Authorized Transaction Data, committed in the digest like the fee, so the choice is fixed before proving. Making a private binding public later is a publish call.
• Defaults: Google is private unless disclosed; X and GitHub are unchanged, and always disclose.
• publish: refused for a handle retired by a later claim, or taken over by another account of the same wallet.
• Private re-claims: a private claim of the published handle keeps the publication; one of another handle clears it.
• Handle rules: Google's handle rules freeze at the first Google binding. After that they change only by contract upgrade.
• Resolution: ENS forward names resolve for private bindings, once the indexer's lookup is keyed by node; the gateway reads the indexer, not the chain. The indexer's plaintext resolve routes stay.

Review

/code-review xhigh raised 15 findings plus 5 smaller ones. All are addressed, in the commits after 543b6c5:

• trust in the pass-through plaintext;
• who chooses disclosure;
• the zero-knowledge assumption;
• reverted calldata;
• the undefined disclosed/published terms;
• the one-sided pairing check;
• the publication-clearing rule;
• escaped sub bytes;
• the unstated buffers;
• the frozen handle rules;
• REQ-PLAT-03 for digest profiles;
• 08B's caller-bytes wording;
• the note's ENS gateway claim;
• the public-input count.

The version-2 finding went away when the digest profile became version 1.

Measured

Gate counts on scratch copies of the circuit at the pinned toolchain (nargo 1.0.0-beta.25, bb 5.2.0):

• today: 179,443;
• with the email digest: 203,878 (+13.6%);
• with both digests: 223,582 (+24.6%).

The noir-lang/keccak256 library compiles under the pinned Noir at v0.1.3, not at the vendored v0.1.1.

Verification

The authoring skill's linter (.agents/skills/trust-min-protocol-specs/scripts/lint_spec.py, run by hand) gives the same count as the pre-existing baseline, with no finding in the changed text. The digest vectors use opaque transactionData, so the new disclose field leaves them valid. Spec references in the note are against origin/main at 002c201; contract, indexer and deployer references are against their origin/main.

Based on main.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	libid	328b7d8	Sep 22 2026, 03:20 PM