Cowrie Research

zkpassport

3 min read

ZKPassport

  • Name: ZKPassport
  • URL: https://docs.zkpassport.id/intro
  • Category: passport-and-ID zk-proof SDK / mobile-first document-proof rail / selective-disclosure identity middleware
  • Summary: ZKPassport is a passport-and-ID proof rail for app integrations, not a broad identity control plane. The important pieces are issuer certificate coverage, mobile proof generation, scoped identifiers, optional facematch and device-trust checks, and the cloud-recursion path used to squeeze proofs into EVM-friendly form.
  • What it does:
    • Lets users scan NFC-enabled passports, national ID cards, and residence permits to generate zero-knowledge proofs of selected attributes instead of exposing the full document
    • Gives applications an SDK to request exact claims such as age thresholds, nationality inclusion/exclusion, or direct field disclosure like first name
    • Derives a domain-and-scope-bound unique identifier from chip data so the same document can be recognized within one application context without becoming globally linkable by default
    • Keeps core passport and ID data on-device, with the mobile app generating proofs locally and sharing only proofs plus deliberately disclosed outputs
    • Supports private facematch flows and device-trust checks, using Apple App Attestation or Google Play Integrity as a gate for some higher-trust proofs
    • Uses open-source Noir circuits and Barretenberg / UltraHonk proving, while also maintaining an optional cloud prover that compresses or recurses already-concealed proofs into EVM-compatible outputs when phones are too memory-constrained
    • Maintains adjacent registry contracts, registry SDK, and registry explorer components alongside the main verification SDK
  • Key claims:
    • The real primitive is document-backed selective disclosure from NFC-readable identity documents, exposed through a request builder and mobile proof flow.
    • The scoped identifier design is one of the few details that matters. Reuse is bound to a verifier domain and optional scope rather than to one global personhood handle.
    • That identifier still carries a privacy/control wrinkle: the docs note an issuer with enough chip data and scope context could recompute it, which is why the vOPRF work matters.
    • The trust model lives in certificate coverage and document support, not in the marketing veneer. If issuer trust anchors, signature schemes, or supported document families are thin, the whole rail narrows fast.
    • Private Facematch and device-integrity checks quietly hand some policy power to Apple, Google, and handset posture rules. That is not fatal, but it is real.
    • The cloud prover is the other meaningful compromise. It keeps raw document data off the service, but it still shows how mobile performance limits can pull a hosted proving layer back into the stack.
    • Keep this note for the passport-proof branch, not as a generic identity anchor. It is a good specimen of how document coverage, mobile policy, cloud recursion, and verifier defaults interact.
  • Whitepaper: No canonical standalone ZKPassport whitepaper surfaced in this pass. The strongest primary materials were the official docs and FAQ, the website, the circuits and cloud-prover repositories, and the monorepo package READMEs collected in ../whitepapers/zkpassport-primary-sources-2026-05-11.md.
  • Sources:

Internal linkages

  • Best read beside self-protocol and upward toward world-id.

  • Use it when the real question is where passport-proof power sits: issuer certificate roots, document coverage, mobile-device policy, and optional cloud proving.

  • Last reviewed: 2026-06-03 UTC

Graph View

Backlinks