Skip to content
Design documentation for a protocol at the proof-of-concept stage. Interfaces are not stable and this describes intended behaviour.

Selective disclosure: the research track

Research only. Nothing on this page is a commitment, a roadmap item, or an implementation. Tenure’s design rules forbid inventing cryptography: the permitted primitives are Ed25519 signatures, BLAKE3 hashing, X25519 with age-style sealing, and a system randomness source — nothing else. BBS+ and zero-knowledge range proofs are outside that set and stay outside it until the criteria at the bottom of this page are met. The selective disclosure Tenure ships is signed bands and thresholds — deliberately not zero-knowledge — and the product copy says so plainly. See Claim families.

Today, issuance mints exact, band, and threshold variants together as one claim family; the worker turns a granularity dial; supersession retires every variant atomically. A band credential is a signed statement of a coarser fact, not a proof that hides the exact value. The known, accepted limitations of this design:

  • Linkability. The same attestation shown to two verifiers is the same signed object, so a colluding pair can correlate the two showings — the attestation identifier and the subject key are shared between them. Per-employer subject keys stop cross-employer correlation, not cross-verifier correlation of one credential.
  • Fixed granularity. The dial has only the positions minted at issuance: bands $25,000 wide, thresholds in $5,000 steps. “Prove income is at least $3,275 per month, exactly” is not a position; the worker shows the nearest coarser fact.
  • The band structure itself leaks. A threshold at $38,400 says something about where the exact value sits within the step function.

These are limitations, not failures — they were chosen, and the product copy never claims otherwise.

BBS and BBS+ signatures — pairing-based, over BLS12-381 in current drafts — sign a vector of messages and let the holder derive, without contacting the issuer:

  • Selective disclosure proofs that reveal any subset of the signed messages while proving the whole vector was issuer-signed, with no need to pre-mint each granularity as its own object.
  • Unlinkable multi-show. Each derived proof is fresh, so two verifiers cannot correlate presentations of the same credential by comparing bytes.
  • Predicate proofs over committed values, in combination with the zero-knowledge machinery below, instead of a fixed menu of pre-signed coarsenings.

In Tenure’s terms: a family’s exact, band, and threshold variants would collapse into one signed message vector, and the granularity dial would become continuous and holder-computed.

What zero-knowledge range proofs would buy

Section titled “What zero-knowledge range proofs would buy”

A range proof — Bulletproofs-style, for example — over an income commitment would let the holder prove that income is at least some verifier-chosen threshold, without revealing the band structure, the step function, or anything beyond the predicate itself. Combined with BBS+, where the issuer signs the commitment and the holder proves the range against it, that closes all three limitations listed above.

  1. Standardisation is not done. The IETF and W3C BBS drafts — the CFRG BBS signature draft and the W3C verifiable-credentials cryptosuite work — were still moving as of early 2026. Building on a moving draft means shipping credentials that may not verify against the final standard, which is unacceptable for objects designed to outlive their issuer.
  2. The dependency conflicts with the allowed-cryptography policy. BBS+ requires pairing-based curves — a new curve, new libraries, and a much larger and younger implementation surface than Ed25519 with BLAKE3. That rule exists precisely to prevent this class of addition under feature pressure.
  3. Audit cost. Every new primitive needs independent audit of the libraries and of Tenure’s use of them, in both implementations, with byte-for-byte vector parity between them. That is a real budget line, not a footnote.
  4. The dependency-free verify page is a product feature. The self-hosted verifier is deliberately small and auditable by inspection. A pairing library plus a range-proof verifier is a step change in what a sceptical verifier must trust — spending the system’s credibility budget to buy privacy properties most verifications do not need.
  5. Bands and thresholds already capture most of the privacy value. The honest observation is that the dominant real-world harm is oversharing exact salary, and signed thresholds already fix that. The residual gains — cross-verifier unlinkability, arbitrary predicates — are real but marginal for landlords and lenders, who identify the applicant by name anyway. Verifier-side linkability of a credential the verifier already ties to a named applicant is not the binding privacy constraint in these flows. See Privacy.

Migration sketch: why waiting costs little

Section titled “Migration sketch: why waiting costs little”

Claim families make disclosure variants additive. A future commitment-based variant could be minted into the same family alongside the exact, band, and threshold variants: same family, same atomic supersession, the same five verification checks, with an added proof-verification step for verifiers that opt in. Old verifiers keep verifying the signed variants they already understand; nothing breaks; no reissuance campaign is needed. The protocol seam already exists — which is exactly why there is no urgency to cut it open early.

This track reopens for implementation consideration only when all of the following hold:

  1. The BBS signature standard is finalised — a published RFC or a W3C recommendation, not drafts.
  2. Two independent, audited implementations exist in the ecosystems Tenure ships in, with published audit reports.
  3. A verifier for the chosen proof system fits the dependency-free verify page budget — self-hostable, no external hosting, auditable at a size a motivated verifier can actually review — or a deliberate decision is made to offer zero-knowledge verification only in the hosted portal, with the trade-off documented.
  4. A concrete verifier segment demonstrates demand that bands and thresholds cannot meet: a paying use case for arbitrary predicates or unlinkability, not an aesthetic preference.
  5. The allowed-cryptography list is explicitly amended, with the same review rigour that produced it.

To be explicit, in the register the product copy uses everywhere else: Tenure does not promise BBS+ or zero-knowledge selective disclosure. No sales conversation, deck, or document may present this track as a committed capability or a dated roadmap item. What ships today is signed bands and thresholds, and the copy says exactly that. If the criteria above are ever met and the work is done, the specification will say so first. Until then, this page is what it appears to be: notes on a question worth revisiting, kept honest.