Privacy Model

The privacy design keeps original identity document images and full OCR output on the user’s device. Selected, separately approved data may be encrypted into a VEID scope; encryption limits who can read a payload but does not make it anonymous or erase its metadata and immutable chain references.

The capture client must clear temporary document-processing copies after local checks. If a user chooses to save a source image, that copy remains only in the user’s local device storage under the user’s control.

The data placement rules

Data	Where it lives	Who can read it
Original identity document images	User’s device only; never uploaded	The user, through the local wallet client
User-reviewed OCR fields and verification features	Encrypted VEID scope, only if the user approves submission	Processed only for the consented purpose under the scope notice
Biometric templates	Encrypted VEID scope, only where separately consented	As described in the biometric scope and trusted-processing design
Device attestation payloads	Encrypted VEID scope only where separately approved	As stated in the scope notice
Identity scope records	On-chain, referencing vault payloads	Public (ciphertext references + metadata)
Verification results	On-chain, signed	Public (result, not the data)
Consent settings	On-chain (encrypted) + off-chain index	User-controlled

The public ledger does not carry source document images or plaintext identity documents. It can carry encrypted payloads or references, key fingerprints, scope identifiers, signed attestations, and results. Designated verification recipients may process data in a submitted scope as described by its notice. Public chain metadata and records are immutable; revoking consent stops future authorized sharing but does not erase existing chain history or copies.

Data minimization

The design calls for data minimization: submit only the minimum data needed for the purpose the user approved. Original identity document images and full OCR output are excluded from VEID submissions. Notable deliberate exclusions:

• veid.geo_location covers country and region, not precise GPS.
• Derived-feature sharing (feature hashes) is off unless the user grants AllowDerivedFeatureSharing.
• Other submitted data follows its own scope lifecycle; chain records and independent copies may persist after consent is revoked.

Zero-knowledge proofs

The x/veid/zk package supports zero-knowledge proofs over identity data: proving a property (for example, that a verified identity meets a policy) without revealing the underlying attributes. This lets relying parties consume assurance rather than data — the strongest form of data minimization the protocol offers.

Enclave-isolated processing

Where verification must touch decrypted data (such as template matching), it happens inside attested trusted execution environments registered in x/enclave — see Encryption & Enclaves. Verification services prove they run approved enclave measurements before they are trusted with decryption tasks.

User rights, operationally

The Consent Framework implements the control surface:

• Access & transparency — consent history is versioned and auditable.
• Revocation — per-scope, immediate, recorded on-chain.
• Expiration — consent can be time-boxed globally or per scope.
• Provider scoping — data sharing can be limited to whitelisted providers per scope.

Compliance posture

The framework is built to align with GDPR (including Article 9 special category handling for veid.biometric), CCPA/CPRA, and BIPA. The governing legal documents live in the repository (PRIVACY_POLICY.md, BIOMETRIC_DATA_ADDENDUM.md, CONSENT_FRAMEWORK.md) and are the authoritative statements of policy; this page describes the technical enforcement behind them.