Explainer · Issue 1

Prove it. Don't show it.

A holder proves a fact about their identity, such as "I am 18 or older". The verifier learns yes or no and never sees the birth date.

Try it in 2 minutes →
Chapter 0

The old way

To prove your age you hand over a full ID card. The checker needs one bit of information and walks away with your name, address, ID number and exact birth date. The card is also easy to copy and replay.

Four weak spots, and how we close them

LeakVerifier sees every field.
Fix · Chapter 3Verifier gets only true or false.
LeakA captured proof can be replayed.
Fix · Chapter 5Every proof binds a fresh nonce.
LeakA stolen credential works on any phone.
Fix · Chapter 6Proofs need a key held in the device's hardware.
LeakVerifying needs the issuer online.
Fix · Chapter 7Works offline over a QR code.

Same question as a paper ID. None of the leaks.

Chapter 1

Who sees what

Three parties take part, and each one knows only what its job needs. Pick a party and a moment to see what that party can see.

Pick a party and a moment

Party
Moment

Each party knows its part, and nothing more.

Chapter 2

Signed once by an authority

The Authority checks you and signs your attributes as one set (BBS+ over BLS12-381). It is not involved again. Verification never contacts it.

What the credential holds

namekept on device
birth_datekept on device
id_numberkept on device
device_public_keyadded by the Authority, signed with the rest

One signature covers every attribute, so none can be swapped or edited later.

The matching private key never leaves the Keystore or Secure Enclave.

These attributes are examples to explain the idea. The fields in a real credential are set by the Authority that issues it.

I sign you once. I never see where you use it.

Chapter 3

A yes, not a value

For "age ≥ 18" the holder builds a range proof. It shows the hidden number sits inside a range without saying where. The verifier gets a single result.

Try it: what each side sees

Prover holdsage = 24
Verifier receivesage ≥ 18 → true

Move the slider. The right side changes only between true and false, and no number ever crosses over.

I know it's true. I don't know the number.

Chapter 4

Only the question is answered

The verifier names the exact predicates it needs. The holder's app answers those and nothing else. No other attribute, and no full document, is ever sent.

One request, one answer

Verifier asksage ≥ 18
Verifier getstrue
Never leaves the phonename, birth date, ID number, device private key

Ask for more predicates and you get more answers. You never get more data.

Ask a question. Get an answer. That's all.

Chapter 5

Fresh every time

The verifier issues a new random nonce for each request. The proof is bound to it, so a recorded proof is useless on the next request.

Replay, step by step

  1. Challenge Verifier sends nonce N1.
  2. Prove Holder builds a proof bound to N1.
  3. Accept Verifier checks the proof against N1.
  4. Replay An attacker resends the same proof to a request with N2.

The replay fails the nonce check: NONCE_MISMATCH.

Proof bound to············
Request carries············
WaitingPress the button to resend the old proof to a new request.

A proof is good for one request.

Chapter 6

Locked to your device

Each proof includes a Schnorr proof of possession, signed by the key in hardware-backed storage and tied to the nonce. Copying the credential to another phone does not copy that key.

Three checks in every proof

  • The signature over the attributes is valid.
  • The predicate holds (for example, age ≥ 18).
  • The device key signed this exact nonce.

A copied credential fails the third check: POSSESSION_FAILED.

The key stays in the chip.

Chapter 7

Works with no signal

For static attributes the request and the proof travel as QR codes in both directions. The verifier needs no network and the Authority needs none either.

The exchange

  1. Show Verifier displays a request QR with the predicate and nonce.
  2. Scan Holder scans it and reviews what is asked.
  3. Answer Holder shows a proof QR.
  4. Verify Verifier scans it and gets true or false.
Request QR
Proof QR

Design only. These are not scannable codes.

No signal needed. Just two screens.

Chapter 8

A credential's life

A credential is issued once, kept on the phone, refreshed when there is signal, used many times, and eventually retired. The last card shows what changes when the verifier has no connection.

Six stages

  1. Enrol The Authority signs the static attributes and the device public key as one credential, once.
  2. Store The credential stays in secure storage on the phone. The private key stays in the Keystore or Secure Enclave.
  3. Sync Whenever there is signal, the phone fetches the latest signed status object and caches it with a timestamp.
  4. Present The verifier shows a request with a fresh nonce. The holder reviews it and answers with a proof.
  5. Verify The verifier checks the proof and marks the nonce used. It learns true or false.
  6. Retire A static credential expires. A revoked or lost one shows up in the next status object.

With no signal at the verifier

Static attributesFully reliable offline. A birth date does not change.
Dynamic attributesCorrect as of the last sync. A lost-phone report may be missed until the verifier reconnects or the credential expires.

Issued once. Checked many times.

Chapter 9

No ceremony needed

Some proof systems need a one-time setup ceremony before anyone can use them. We chose tools that need none, so there is no setup secret to protect.

Compare the two approaches

Setup-based proofsA one-time ceremony creates the public parameters. If the secret behind them leaks, forged proofs become possible. Each statement also needs its own circuit.
This systemNo ceremony. Proofs use public mathematics (BBS+ and range proofs). The Authority's signing key is still trusted, which Chapter 11 states.

Nothing to set up, so nothing to leak.

Chapter 10

Anyone can check

Every guarantee comes from public mathematics. A verifier can confirm each of the five checks below without trusting us.

What a verifier confirms

  • The credential was signed by a known Authority key.
  • The predicate proof is valid for the stated range.
  • The nonce matches the one this verifier issued.
  • The device key proved possession of that nonce.
  • The attribute proofs are tied to the same signed credential.

Change any one part and the matching check fails by name.

Don't trust us. Check.

Chapter 11

What we don't claim

Every design rests on assumptions. These are ours.

The Authority's own mistakes

If the Authority signs a false birth date, the proof of it is valid too.

One trusted Authority

For now the design relies on a single trusted Authority. Sharing that trust across several is a later option.

A shared phone

The device key is released after the owner's biometric or PIN. Someone the owner hands an unlocked phone to can still use it.

Changing attributes offline

Offline checks of dynamic attributes are as of the last sync. A lost-phone report may not be caught until the verifier reconnects or the credential expires.