Privacy by default
Disclosure by choice
Identity verification requires sharing data to prove anything about it. Zentity is the cryptographic layer that separates the two. Verify once through any provider, then produce proofs on demand. The verifier learns the answer. Nothing else.
Users - prove facts without revealing data
Companies - verify without collecting
Developers - integrate with standard OAuth/OIDC
One flow, three concerns
Users, companies, and developers interact with the same proof-first disclosure flow. What varies is what each cares about: what is revealed, what is retained, or how to integrate.
Service requests eligibility proof
The service asks for a minimal verification result first.
User reviews and consents
The user sees exactly what is being requested before any personal detail is shared.
Proof result is returned
The service receives a yes/no style result for the requested policy.
Identity disclosure is optional
Extra identity fields are requested only when required.
Outcome
Users get verified without becoming a reusable identity record.
Will this expose my identity?
No. Most checks return a simple result first. Personal details are requested only when policy or law requires it.
Each request is limited to what that service needs.
Personal details require explicit consent each time.
Document images and selfies are processed and discarded.
What makes verification without disclosure possible
Each primitive breaks a different link between knowing data and using it. Together they ensure that verification never requires revelation.
Zero-Knowledge Proofs
Prove claims without revealing data
A verifier confirms eligibility without seeing the data behind it. Prove you are over 21 without revealing your birthday. Prove EU citizenship without naming the country.
Verifier learns: eligible. Nothing about your name, address, or birth date.
Fully Homomorphic Encryption
Compute on encrypted data
The server evaluates compliance rules without decrypting the data. Age thresholds, liveness scores, and sanctions checks all run on ciphertexts.
Server computes on ciphertext. Results are decrypted with user-held keys.
Cryptographic Commitments
Verify without storing
Evidence is bound for integrity and audit without being stored in reversible form. Commitments prove that verification happened. They cannot reveal what was verified.
Commitments remain verifiable while sensitive profile fields stay in encrypted secrets.
Multi-Credential Key Custody
Your keys, your control
The server stores encrypted blobs it cannot read. Only the user's credential, whether passkey, password, or wallet, unlocks them. Three paths, one custody model.
Encrypted profile data remains locked unless the user approves credential-based unlock.
Scenarios where verification must not require revelation
These scenarios share a structural need: proving a fact without disclosing the data behind it. What varies is the fact being proved, the depth of disclosure required, and the stakes of a privacy failure.
Threshold Proofs
Age-Restricted Access
A retailer, a platform, or a regulator needs to know 'old enough.' The date of birth is irrelevant to the decision. A threshold proof answers the question without creating the liability.
Threshold Proofs
Jurisdiction Eligibility
A crypto exchange needs 'eligible jurisdiction.' Which country is irrelevant to the transfer. A Merkle membership proof confirms group inclusion without naming the member.
Graduated Trust
Banking Step-Up
Viewing a balance requires basic login. Wiring funds requires document-verified identity. The scope model handles both without treating every user as a compliance case from the start.
Graduated Trust
Compliance-Gated Finance
Sanctions screening, ongoing monitoring, and Travel Rule reporting need encrypted attributes that can be re-evaluated without re-collecting. FHE computation addresses this without storing plaintext.
Bound Delegation
Agent Delegation
An AI agent needs the human's name to ship a package. CIBA sends a push notification; the human approves and unlocks their vault. The agent receives a one-time release handle, never the raw identity.
Portable Trust
Portable Verification
Standard OAuth redirect with pairwise pseudonyms, or SD-JWT credentials the user carries between services. Either way, each relying party sees only the claims the user approves, and cross-service correlation is impossible.
How the architecture enforces privacy
Privacy is a consequence of how these components depend on each other, not a feature added on top.
Privacy-Preserving Flow
Data Extraction
OCR extracts fields; images discarded; claim hashes created.
Proof Generation
Client unlocks encrypted profile with your credential, then proves eligibility with zero-knowledge proofs.
Verification
Server verifies proofs and stores signed attestations, commitments, and encrypted artifacts. Identity disclosure requires user consent.
OAuth/OIDC scope progression
- Sign in with proof scopes
- User starts a higher-risk action
- Request identity scopes when required
- Return scoped response and continue
Regulatory alignment
Zentity is a cryptographic verification layer, not a compliance service. These mappings describe how the architecture's privacy properties align with regulatory frameworks. They are not certifications or legal guarantees.
Compliance frameworks
| Framework | Regulatory scope | Architecture mapping |
|---|---|---|
| GDPR | EU data protection | Data minimization and selective disclosure support |
| AMLD5/AMLD6 + AMLR | EU AML and customer due diligence | Verification evidence trails and retention-aware workflows |
| MiCA | EU crypto regulation | Exchange-oriented identity checks and compliance proofs |
| eIDAS 2.0 + EUDI wallet direction | EU digital identity interoperability | OIDC4VCI, OIDC4VP, and OIDC4IDA compatibility pathways; HAIP wallet attestation alignment |
| FinCEN CIP + BSA | US banking and AML | Identity scopes for regulated disclosure when required |
| FATF Travel Rule | Cross-border crypto transfers | Policy-driven claim release and auditable payload boundaries |
This is architecture mapping guidance, not legal certification or legal advice.
Standards implemented
Identity & interoperability
- OAuth 2.1 authorization code flow
- OpenID Connect (OIDC)
- RFC 7591 Dynamic Client Registration
- SD-JWT Verifiable Credentials
- OIDC4VCI / OIDC4VP / OIDC4IDA profile
- HAIP (High Assurance Interoperability Profile)
Transport security
- RFC 9126 Pushed Authorization Requests (PAR)
- RFC 9449 DPoP (Demonstration of Proof-of-Possession)
- JARM (JWT Secured Authorization Response Mode)
Agentic authorization
- Agent Auth Protocol v1.0-draft (agent identity and lifecycle)
- OpenID Connect CIBA Core (backchannel consent)
- RFC 9396 Rich Authorization Requests (RAR)
- RFC 8693 Token Exchange (delegation chains)
- draft-ietf-oauth-first-party-apps (headless bootstrap)
Cryptography
- Post-quantum migration alignment (FIPS 203/204)
No custom protocol is required. Teams can integrate through OAuth/OIDC scopes and user-approved claim sharing.
Technical documentation paths
Technical and privacy documentation for engineering, security, and compliance reviews.
System architecture
Trust boundaries across web, OCR, FHE, and evidence services.
Attestation privacy model
What stays encrypted, what is transient, and what is disclosed by scope.
OAuth/OIDC integration
Scope contracts for banks, exchanges, and other relying parties.
Cryptographic pillars
Passkeys, commitments, ZK proofs, FHE, and post-quantum migration.
Agent architecture
How agent identity, human consent, and pairwise delegation compose into a single binding chain.
Integrate verification without collection into your stack
Start with the demo to see the full verification flow, then integrate via standard OAuth 2.1