Singpass ZK playground

For Singpass developers and relying-party integrators: generate a browser-local Plonky3 proof for a staging ID token, inspect the verifier envelope, and compare the browser-side witness with what a verifier receives.

This use case originated from a relying-party flow that needs to prove a Singpass-signed token and a UUID commitment while sharing only a redacted payload, public proof data, and verifier-safe metadata.

Fixture Source

Start from the checked-in staging token, generate a fresh Singpass staging token, or paste a compact JWS. The randomizer binds the UUID commitment without being exposed to the verifier.

open fixture generator

Staging token

checking browser storage...

UUID commitment randomizer

fresh randomizer ready

Readable JWT-Style View

The left pane is the token data available to the browser-side prover. The right pane is the redacted payload that can be placed in a verifier envelope.

UUID used for commitment loading...
Browser witnessprivate
Redacted resultpublic policy

Hashes and Signature

Two checks matter here: the Singpass ES256 signature over header.payload, and a randomized commitment to the subject UUID used by the proof.

JWS signature hashSingpass issuer check
signed bytes loading...
SHA-256 header.payload
ES256 loading...
signed-body digest loading...
signer key loading...
checking signature...
UUID commitment hashrandomized
UUID from payload loading...
private randomizer ****************
SHA-256 loading...
UUID commitment digest loading...
waiting for fixture...

Redaction Bitmap

Each cell is one decoded payload byte. Highlighted cells are replaced with * before the envelope is shared.

Hidden bytes and UUID position loading...

Fixture Artifacts

redacted bytesloading...
UUID commitment inputloading...

Generate Proof

The proof is built in the browser worker. The trusted envelope carries the proof, public values, redaction policy, redacted payload, and commitment checks. The additional issuer-binding presentation includes the original ES256 signature so an application verifier can authenticate the same STARK public hash against trusted Singpass JWKS.

JWT Singpass ID token loading
*** Redaction bitmap loading
UUID UUID commitment private randomizer
ZK Proof not generated
ENV Envelope not generated
OK Verifier waiting
1. Fixture loaded
2. Proof generated
3. Envelope verified

Envelope Boundary

Envelopeverifier receives
Witnessstays in browser

Proof Results

proof generationnot run
self verificationnot run
proof sizenot run
envelope sizenot run
technical metadata

              

Verify Envelope

This playground view verifies the trusted proof envelope: no raw token, no UUID randomizer, only public proof data and the redacted payload. Production authentication should verify the document-binding V2 presentation with the complete document, current trusted Singpass JWKS, and application claim policy. Document binding is implemented; replay protection still requires a separate verifier challenge.

Verifier-Visible Data

Envelope contentsvisible
Hidden witnesskept out of envelope

Hash Relations

Signed payload relationJWS branch
redacted payload proof waiting
SHA-256(header.payload) waiting
ES256 signature waiting
digest waiting for fixture...
UUID commitment relationZK branch
redacted sub "************************************"
hidden UUID + randomizer inside witness
commitment digest waiting
digest waiting for fixture...
waiting for envelope...

Verification Results

envelope verificationnot run
circuitnot verified
envelope bytesnot verified
technical metadata

              

Secret Scan

first bytes and parsed metadata