Recommendation for maintaining a prioritized list of requested ZK proofs

[talltree]

DTG ZKP Task Force: on today's TF call, we discussed creating and maintaining a prioritized list of the ZK proofs that we need (for example, those required or recommended by our other specs or by market feedback on DTG implementations).

I wondered what the easiest way for the DTGWG to maintain such a list would be, so I asked an AI friend and got this recommendation:

GitHub Project Board with a Priority Column (best overall fit)

A GitHub Project (the newer Projects v2) is purpose-built for exactly this use case:

• Create a Project attached to your working group's GitHub organization or repo
• Add a custom "Priority" field (single select: P1/P2/P3, or High/Medium/Low, or numbered ranking)
• Use issues as work items — each issue represents one work item with description, discussion, assignees, and status
• The Project board gives you a sortable, filterable table view that can be re-prioritized by dragging or editing the priority field
• Changes are tracked with timestamps and attribution — you always know who changed what and when
• Weekly updates are as simple as opening the Project and adjusting priority values
• Accessible to anyone with a GitHub account, including read-only access for observers

Why this wins: It keeps everything in GitHub (no context switching), ties work items directly to actual issues where discussion happens, and has a full audit trail.

[ScottJeezey]

Thanks Drummond, I like it. A Projects board with a priority field is the right home for tracking: priority, status, owner, all in one place. +1.

One thing to add so the list is something we can build from, not just sort. Each proof needs a bit of substance behind the row: what it proves, over which credentials, and what it does not establish. Enough that someone can take an entry to the registry and try to rebuild the circuit from it. So each board item links out to a thread or short entry with that detail, and the board stays light.

Glenn's ADR-001, the Community-Anchored Proof, is a good template for a fully specified item and a natural first one to seed it with. Happy to set the board up and take a first pass. Mitchell, Denys and I can split it, me on the board, them on the construction detail.

Cheers,
Scott

[talltree]

@ScottJeezey 100% agreed. Sounds like an excellent action plan.

[mitchuski]

agreed with this path, a board + linked detail is the right shape.

initial construction-details;

Format for the linked entry, so every item is buildable from the page:

statement in one sentence · witness (what stays with the holder) · public inputs · clauses each bound to a gadget · disclosure set · what it does not establish · adversary and horizon per privacy clause · fixture families (accepts / rejects-unsatisfiable / rejects-verify / unlinkable / current) · construction options with measured cost · what it requires of issuers · provenance (catalog entry, registry row).

Primitive entries (membership, nullifier, transcript binding, distinctness, non-revocation) and composed entries (a named conjunction under one transcript and one disclosure set) are different rows, because a composition's disclosure set is not the union of its parts.

ADR-001 as the first composed item: its clause 3 is native to the vouchable-credential model in 2026/333 (a vouch that verifies under the community's key is the statement that the voucher holds that community's credential), and the lab's membership, distinct-issuer and transcript-binding circuits already cover the method with measured numbers.
Four refinements will go into the detail thread: membership is now a mutually issued pair (cred-spec #8 → PR #12), so clause 3 proves the grant half; a missing S6 (voucher ≠ holder, provable as distinctness - otherwise a self-vouch verifies); P4 parameterised by context per the trade curve; and X3 made concrete. The credential signature or a published commitment must be ZK-friendly, which touches cred-spec #17.

The seed set and the entry format are drafted as cards in the agentic evidence repo dtgwg-zkp-mage; each row on the board can link to an observable runtime.

[mitchuski]

Seed set update. The linked-entry format proposed above is now the construction-record form in the ZKP specification draft (trustoverip/dtgwg-zkp-spec, draft PR #8); each board row can link a record id. Twelve records, all validating.

From cred-tf #39 and #40, the ZKP TF work items on record: 008 blinded binder (salted-commitment route proposed, not measured for this record; PRF-derived per-context pseudonym as the fuller construction) · issuer-as-predicate as the alias of 001 · delegation-chain validity as 020, carded with the acceptance clause and the core/profile split from the #40 design note (the single-hop core needs no chain proof; the record proves the chained profile) · the set-root primitive as a construction option on 006 and a public-input convention, flagged as the priority pressure-test.

From cred-spec WD02 (#22 → PR #30, three correlation scopes): 007 common control across identifiers — the linkage #31 says four things now lean on, answered on #9 — and 012 intentional correlation, the one case identified there as still needing a proof. 010 and 011 are re-carded in the WD02 vocabulary with the common-control clause added; 010 now lists the voucher-side linkage as a witness ingredient rather than assuming it.

Proving systems: four entries — the reference Groth16 lab (the only one with registry rows), ProveKit, the SIROS catalog, Flock — recorded as facts with sources, not recommendations.

I’m adding the construction refinements as a follow-up here, so the board can point to this existing discussion.

[mitchuski]

Following up on my earlier construction notes for Glenn’s ADR-001, I’ve refined the Community-Anchored Proof record and the questions we’re taking into the specification.

Two points in my earlier comment need more precise wording. Distinct membership leaves reject reuse of the same leaf; they do not establish distinct people or prevent one controller holding two memberships. And the lab’s transcript-binding constraint binds the presentation to a request; it does not by itself establish the paper’s tagged simulation-extractable NIZK property.

The main construction question is the offline voucher’s linkage: what authenticated artifact lets the presenter establish that the voucher’s relationship identifier and community-membership identifier belong to the same controller? That linkage needs to be supplied at issuance or follow from deliberate identifier reuse under the chosen scope. It cannot be inferred from the presenter’s own secret.

I propose carrying these requirements into the detailed record:

• State that the offline membership check covers the community-issued grant half; it does not establish the voucher’s acknowledgement.
• Specify credential authenticity, both parties’ identifier linkage, status freshness and the shared witnesses needed for the composed proof.
• State the adversary, disclosure set and validity horizon for each privacy claim. A context nullifier is an intentional link within that context; other disclosed metadata may also correlate presentations.
• Keep rejected witnesses distinct from verifier-side rejection tests, and compare constructions against the same credential format and statement.

The vouchable-credential model gives us a useful basis for this, but the DTG issuance artifacts and complete composition still need to be established. The existing component measurements are evidence for those components, not an end-to-end implementation of ADR-001.

Would this be a useful next revision of the linked construction detail for the first board item? I’d particularly welcome Glenn’s and the cryptography team’s view on the offline linkage artifact and the smallest representative implementation.