Blueprints for a zero-knowledge identity and credential platform in high-trust environments

Blueprints for a zero-knowledge identity and credential platform in high-trust environments

Explore concrete architectures for e-voting, banking KYC reuse, and mobile identity. Zakapi combines regulator-ready, PoneglyphDB-style non-interactive zero-knowledge proofs over committed registries, open standards, and privacy-first design to show how secure, cross-border verification works in practice.

Secure e-voting with verifiable credentials

Facilitate secure e-voting by issuing citizens verifiable credentials anchored to committed national registries, then using anonymous ZK proofs to access voting portals. Policy rules like “exactly one vote per eligible person” become cryptographically enforced predicates over those registries, ensuring one vote per person, preventing fraud, and strengthening trust between identity authorities and election commissions.

National ID
A citizen receives a national ID credential in their Zakapi Wallet, bound to a committed population register and signed by the ID authority.

Voter eligibility
They are issued a voter-eligibility credential derived from the same registry (e.g., age, residency, registration status, election and district), proven via zero-knowledge without exposing full records.

Anonymous proofs
The citizen uses anonymous, non-interactive proofs from their wallet to access the e-voting portal—verifying eligibility and “has not voted yet” against committed data, while keeping their real identity and underlying attributes private.

Architecture Narratives (Gov, Bank, Telco)

In this section, we provide narrative “architecture diagrams” in text form to illustrate how Zakapi works in real-world deployments. Each scenario walks through the actors, steps, and trust points involved, showing how SQL-like policies over committed datasets turn into proofs your regulators can verify.

A. Government National ID + Voting Deployment

Actors

• Citizen Alice – holds national ID and voter credentials in her Zakapi Wallet.

• Ministry of Interior (ID Authority) – issues the base national ID credential as a verifiable credential, anchored to a committed population registry.

• Election Commission – issues voter-eligibility credentials and runs the voting system.

• E-Voting Portal – the online or in-person system where votes are cast and proofs are checked.

Credential setup

1 National ID issuance

◦ Alice completes ID proofing with the Ministry (in person or via existing eID).

◦ The Ministry uses Zakapi’s Issuer Service to issue a National ID credential to Alice’s wallet, signed under the government’s DID and backed by a cryptographic commitment over the population registry.

2 Voter credential issuance

◦ Before the election, the Election Commission derives an eligible voters list from the committed registry.

◦ Using Zakapi in batch mode, it issues each voter a Voter Eligibility credential (e.g., “eligible to vote in Election 2025, District 7”), keyed to their DID or ID reference.

◦ The credential is designed to support a “one-use” style proof (e.g., via accumulators or status lists) so that “has NOT voted” can be proven once.

Voting process

1 Proof request

◦ Alice goes to the E-Voting Portal.

◦ The portal creates a Zakapi proof request for two predicates over committed data:

▪ Predicate 1: “Holder has a valid voter credential for Election 2025 in District 7.”

▪ Predicate 2: “This credential is not yet in the ‘voted’ set / status list.”

2 Wallet approval & proof generation

◦ Alice’s Zakapi Wallet opens via QR or deep link:
“Election 2025 is requesting proof that you are an eligible voter in District 7 who has not yet voted.”


◦ On approval, the wallet generates a non-interactive ZK proof:

▪ Shows the credential is issued and signed by the Election Commission.

▪ Proves the election + district fields match the request, in zero-knowledge (no need to reveal name, ID number, etc.).

▪ Proves, via an accumulator or status list, that this credential has not been marked as used.

3 Verification & ballot access

◦ The portal uses Zakapi’s verifier library to:

▪ Check signatures and issuer trust.

▪ Verify the ZK proof against the committed registry and status list.

◦ Once valid, the portal:

▪ Marks this credential or its identifier as “used” (updating the commitment / status).

▪ Grants Alice access to the ballot (handled by a system like ElectionGuard for end-to-end verifiable tallying).

4 Post-vote state & auditability

◦ Alice’s wallet can record an activity log entry (“You voted in Election 2025 at 10:32”), and optionally receive an updated status.

◦ The Election Commission keeps a tamper-evident log of proof verifications, each entry representing “one eligible credential used exactly once.”

◦ Auditors can check that:

▪ Every accepted proof chains back to a valid credential signature.

▪ The count of valid proofs equals the number of votes—without revealing which citizen produced which proof.

Trust & security

• Citizens know their credentials are only used to produce minimal, anonymous proofs; their name never has to hit the voting backend.

• The government relies on cryptographic commitments and proofs to ensure:

◦ Only eligible voters vote,

◦ No double voting,

◦ No forged identities.

• Attempts to vote twice fail because the second proof cannot satisfy “has NOT voted.”

• Stolen credentials are useless without the user’s private key and wallet access.

B. Bank / Fintech Deployment

Scenario: FinBank uses Zakapi for customer onboarding and login. FinStartup, a fintech, reuses FinBank’s KYC through PoneglyphDB-style proofs over FinBank’s committed KYC dataset.

Actors

• User Bob – customer of FinBank, now onboarding at FinStartup.

• FinBank – regulated bank, original KYC performer and credential issuer.

• FinStartup – fintech app relying on FinBank’s KYC via proofs, not raw documents.

• KYC Provider Co. (optional) – external KYC/AML vendor FinBank uses.

Credential issuance at the bank

1 Bob completes KYC with FinBank (traditional or via Zakapi).

2 Once verified, FinBank uses Zakapi Issuer to create a “KYC Complete” credential:

◦ Attributes like name, DOB (or hashed/encoded), KYC date, AML status, residency.

◦ Signed by FinBank and anchored to a committed internal KYC registry.

◦ Delivered to Bob’s Zakapi Wallet.

Now Bob carries a portable, bank-signed KYC credential that can be used elsewhere via proofs.

Login at FinBank

• FinBank adds “Login with Zakapi”:

◦ Bob scans a QR or deep links from FinBank’s app.

◦ Zakapi Wallet receives a request: “Prove you’re Bob (customer ID X) at FinBank.”

◦ Wallet produces a proof of possession of the FinBank credential (or dedicated login credential).

◦ FinBank verifies and logs Bob in, passwordless and phishing-resistant.

Sharing KYC with FinStartup

1 FinStartup onboarding asks Bob to “Verify with your bank via Zakapi.”

2 FinStartup requests a proof:

◦ Issuer must be on a trusted list (e.g., FinBank).

◦ Predicate: “KYC done and clear; age ≥ 18; country = allowed jurisdiction.”

3 Bob’s wallet:

◦ Uses the FinBank KYC credential.

◦ Discloses only what FinStartup needs (e.g., name, maybe masked ID), plus ZK range proofs for age and other predicates.

4 FinStartup:

◦ Verifies the proof with Zakapi’s SDK:

▪ Checks FinBank’s signature and DID.

▪ Validates ZK proofs over FinBank’s committed KYC dataset.

◦ Marks Bob as verified, stores minimal identity facts and a reference to the proof event.

Ongoing compliance

• When FinBank refreshes Bob’s KYC or sanctions screening, it updates/reissues the credential.

• Next time FinStartup requests a proof, Bob’s wallet uses the updated credential and FinStartup’s policy might say “AML check < 1 year old.”

• Compliance refresh happens implicitly through new proofs, without FinStartup ever redoing KYC from scratch.

Audit & privacy

• FinStartup can show regulators cryptographic logs:

◦ “Customer Bob was verified by FinBank (an approved KYC provider) on date X; we hold minimal attributes and a verifiable proof.”

• FinBank proves to its own regulators that only properly KYC’d customers receive credentials.

• Bob’s privacy is preserved:

◦ FinStartup never sees passport images or full document numbers, only what’s needed and what the law requires.

C. Telco SIM Registration + Mobile ID Deployment

Scenario: TelcoCo uses Zakapi for remote SIM registration and becomes a Mobile ID provider to other services, using reusable credentials and ZK proofs instead of fragile SMS OTP.

Actors

• User Charlie – subscriber buying or activating a SIM/eSIM.

• TelcoCo – telecom operator required to KYC SIM owners.

• Government eID – national ID or eID wallet Charlie already has.

• GovPortal – government or third-party service using TelcoCo as an identity provider.

Remote SIM registration

1 Charlie orders a SIM/eSIM online.

2 TelcoCo must verify identity and (often) age:

◦ Offers “Verify with National eID / Bank via Zakapi.”

3 Charlie’s wallet:

◦ Shares a proof from a government or bank credential:

▪ Reveals name and minimal info TelcoCo must store (e.g., ID type and number).

▪ Proves age ≥ required threshold via ZK range proof.

4 TelcoCo:

◦ Verifies the proof, issues the SIM, and optionally issues a Mobile ID / SIM Ownership credential to Charlie’s wallet, tied to the phone number and their verified identity.

Mobile ID authentication

1 Charlie visits GovPortal and chooses “Login with Mobile ID (TelcoCo).”

2 GovPortal sends an auth request to TelcoCo (OIDC/SAML).

3 TelcoCo uses Zakapi to request a proof from Charlie’s wallet:

◦ “Prove you own number +X and are the verified identity TelcoCo registered.”

4 Charlie approves; wallet uses the SIM Ownership credential plus ID linkage to:

◦ Prove control of the number and the underlying verified identity.

◦ Reveal just enough info for GovPortal (e.g., name, ID reference) while keeping other attributes private.

5 GovPortal logs Charlie in with phishing-resistant Mobile ID, not SMS OTP.

Security & fraud reduction

• SIM registration is backed by government-grade credentials instead of weak document uploads.

• Mobile login uses ZK proofs and wallet approvals instead of OTPs that can be SIM-swapped.

• Attackers can’t log in with just a hijacked SIM; they’d need Charlie’s wallet and biometric/PIN as well.