Threat model and remaining risks
Trust boundaries
Provers may be malicious; applications may collude; submissions may race, replay or be tampered with; members may be suspended, permanently revoked or restored from backup. Trusted components include the local eligibility manager, configured issuer public key, current membership database, SQLite filesystem locks, Semaphore circuit/verifying key, Groth16 trusted setup and host. Compromised administrators or hosts are outside this prototype’s protection. Decentralized governance and multi-host consistency are not provided.
Implemented protections and evidence
Real Groth16 verification and current-root comparison reject non-members and stale roots. Rechecking the root inside the acceptance transaction prevents revocation races during verification. Canonical decimal encoding prevents nullifier aliasing. Proofs bind the message, application, activity and epoch. A composite SQLite unique key enforces one consumption per scope; four independent Node processes produced exactly one success. Persistence and same-secret recovery tests preserve spent records across restart and recovery.
Nullifiers differ across applications/epochs, and public proof fields omit the identity commitment. This is regression evidence, **not a proof of cryptographic unlinkability**. Nullifiers are deliberately stable within a scope. Different randomized Groth16 points do not prove anonymity. A shared membership root identifies a group; application, scope and message are public.
Unresolved issues
1. **Anonymous issuance:** the issuer sees the member commitment. Synthetic permits use Ed25519 signatures, not blind signatures or anonymous credentials. Issuance timing, insertion logs and one-person groups may link use. A malicious issuer can add arbitrary members; natural-person uniqueness is not guaranteed.
2. **Recovery linkage and lost keys:** recovery explicitly uses the original commitment and token, allowing the manager to link it. The original identity secret must be backed up; the token cannot reconstruct it. Recovery with a replacement secret is unsupported and could create new nullifiers and duplicate participation. Restoring a stolen secret does not exclude its thief. Permanent revocation is irreversible. Private recovery with new secrets and continuous replay protection remains undesigned.
3. **Biometric deduplication/personhood:** E03/E04 use random synthetic identities; permit fixtures can authorize any new key. E01 is a small, semi-honest, three-process synthetic-vector MPC experiment. It does not establish real-population error rates, liveness, deepfake resistance, malicious security, operator independence or million-user performance. No complete composition proof links anonymous issuance with MPC outputs.
4. **Metadata and active attacks:** IP, devices, timing, distinctive messages, small anonymity sets, personalized roots, revocation differencing and colluding applications sharing a scope can defeat anonymity. Large stable shared groups, trustworthy domain registration, client scope validation, anonymous transport and batching are needed and are not implemented here.
5. **Old proofs after recovery:** only the current root is accepted. Suspension invalidates the root; restoring the same commitment may restore the old root and make an unspent old proof valid again. Spent proofs remain rejected. Permanent revocation does not restore membership. Forced proof expiry needs independent freshness checks without resetting nullifier scope.
6. **Availability/deployment:** each membership change invalidates existing roots for other members. No historical-root grace period is provided, as it would delay revocation. A 16-member limit, rebuilding groups and reverifying concurrent proofs do not establish production throughput. DoS limits, audited governance, rollback-resistant backups, crash injection, independent audit and cryptographic side-channel tests are incomplete. Database rollback or replica forks can reset replay protection.
7. **Separation and business atomicity:** the experimental database stores commitments, recovery token digests and spent records together; administrators may correlate timing and side information. Unlinkability after database compromise is not claimed. Applications should not receive this database. There is no network API; management methods are for trusted code. Real business writes must share the spent-record transaction; accept currently consumes eligibility only.
8. **Non-transferability:** exportable secrets can be shared or transferred. No secure-hardware attestation is provided.
9. **Supply chain:** dependency audit results are recorded. Pinned dependencies and artifact hashes support reproduction and tamper detection, not proof of benign dependencies or a secure trusted setup. At this historical report’s date, Docker was not running and containers were unexecuted. Node tests used --test-force-exit to terminate upstream proving-library workers; MaxListenersExceededWarning occurred and long-running resource behavior was unverified.
Real computation versus synthetic fixtures
Real: Semaphore generateProof/verifyProof, Groth16 arithmetic, SQLite transactions, multiprocess contention and Ed25519 signature verification. Synthetic/fixtures: identities, issuance permits, application names, epochs, vote values and scenarios. No always-true verifier or hash-based imitation of ZK was used. E01’s synthetic inputs and real MPC execution have a separate report; simulated human uniqueness does not solve biometric deduplication.