ZKPassport’s cleanest contribution is not a generic identity app but an application-facing passport-and-ID proof rail. The intro and SDK docs frame the product around requesting specific attributes from passports, national IDs, and residence permits rather than exporting a broad identity profile.
The request-builder flow is analytically important. The SDK README shows applications ask for exact predicates like gte("age", 18), in("nationality", EU_COUNTRIES), or direct field disclosure, then receive a result bundle plus a verified flag and a scoped unique identifier. This makes verifier policy and SDK defaults a real control plane.
The FAQ is unusually explicit that core proof generation happens locally on the user’s device. The app reads NFC chips, extracts relevant data, and generates zero-knowledge proofs on-device so raw passport/ID data never leaves the phone unless the user explicitly shares it.
The domain-and-scope-bound unique identifier is one of the most reusable mechanism details. The FAQ says it is derived from chip data plus domain and scope, which makes repeated-user recognition a configurable app-specific surface rather than a mandatory global identity key.
The same FAQ also surfaces an important caveat: a party with complete chip data plus domain and scope could recompute that identifier, and ZKPassport says it is working toward salted identifiers via vOPRFs. That makes nullifier design and issuer-side recomputability an active design question, not solved plumbing.
The circuits repository is the strongest source for the lower-layer trust model. It explains the chain from chip data signatures to document-signer certificates to country-signing certificate authorities under ICAO 9303, which makes ZKPassport a useful comparison point for any system that treats government documents as trust roots.
The circuits docs also broaden the comparison class beyond passports: ICAO-style national IDs, residence cards, visas, and other document families matter because support coverage and signature-scheme handling become governance/compatibility surfaces.
The FAQ’s Private Facematch section reveals another hidden control plane. Higher-trust proof modes can depend on Apple App Attestation or Google Play Integrity, and may fail on rooted devices, GrapheneOS, unsupported manufacturer signing schemes, or devices with insufficient security guarantees.
The cloud prover README adds a meaningful architectural split. It says sensitive passport/national-ID data never leaves the device, but also shows that proof compression / recursion into final EVM-compatible proofs may rely on an AWS Fargate-based service when phone memory is insufficient. That hosted proving layer should be kept distinct from the underlying local-proof story.
The monorepo README matters because it shows the project is already broader than one SDK: registry contracts, a registry SDK, and a registry explorer sit beside the main ZKPassport SDK. That suggests adjacent onchain certificate/proof-management surfaces that can accumulate power separately from the mobile verifier flow.
The SDK README also explicitly warns the software is experimental and unaudited. That current maturity posture is worth retaining because many identity systems present polished demos before their trust surface is operationally mature.
Why it matters for the corpus
It gives the corpus a clearer passport / NFC-document zk middleware comparison point that is more SDK-and-integration-centric than broader umbrella systems like Self Protocol or Human Passport.
It helps separate document-authenticity verification, mobile proving, device attestation, verifier-side query design, scoped nullifier policy, optional cloud recursion, and registry export into distinct layers instead of flattening them into one generic proof of personhood label.
It sharpens comparison against Rarimo, Self, Human Passport, Zupass, and other identity systems by foregrounding where practical power sits when document-backed proofs become productized.
Follow-up comparison threads
Compare ZKPassport directly against Self Protocol and Rarimo’s ZK Passport so issuer-key management, supported document families, local-versus-hosted proving, nullifier derivation, and downstream registry/export surfaces do not get flattened together.
Compare ZKPassport directly against Human Passport and Zupass so passport-backed selective disclosure, credential aggregation, proof-container UX, device-trust gates, and verifier integration defaults do not get flattened into one generic identity bucket.
Compare ZKPassport directly against Anon Aadhaar and other narrower document-proof rails so document-family breadth, issuer-root assumptions, face-match requirements, and onchain-verifier posture remain legible as separate variables.