zkMe Self-Sovereign Identity
zkMe Self-Sovereign Identity empowers users with full control over their credentials, blending privacy, security, and decentralization to transform how identity verification is performed.
What Is Self-Sovereign Identity?
Self-Sovereign Identity (SSI) is an identity model that gives individuals full ownership and control over their digital identity, without depending on any centralized authority. Unlike traditional identity systems where a government database, a social platform, or a corporate directory is the ultimate source of truth, SSI places the individual at the center of the trust relationship.
The concept rests on three foundational principles:
User Control. The individual decides what information to share, with whom, and for how long. No third party can access, revoke, or modify the individual’s identity data without their explicit consent.
Portability. Identity credentials are not locked into a single platform or service provider. A credential issued by one entity can be verified by any other entity that trusts the issuer, across organizational and jurisdictional boundaries.
Minimal Disclosure. Verification should require only the minimum information necessary. To prove you are over 18, you should not need to reveal your exact date of birth, your name, or your address.
SSI is typically implemented using Verifiable Credentials (VCs) and Decentralized Identifiers (DIDs) as defined by the W3C. A VC is a tamper-evident, cryptographically signed digital credential. A DID is a globally unique identifier that the individual controls, anchored on a decentralized ledger rather than a centralized registry.
How zkMe Implements SSI
zkMe builds on the W3C SSI framework but introduces several innovations to address the limitations of traditional SSI implementations, particularly in the context of compliance-gated applications and the emerging Agent Economy.
The key differentiators of zkMe’s SSI implementation are:
Zero-Knowledge Proofs as the default presentation format. In standard SSI, a Holder presents a Verifiable Presentation (VP) that may contain the actual claim values. In zkMe, the default VP format is a Zero-Knowledge Proof (ZKP) that proves a claim is true without revealing the underlying data. This is not an optional feature; it is the fundamental operating mode.
On-device ZKP generation. The ZKP is generated entirely on the Holder’s device using open-source, audited algorithms. The raw credential data never leaves the device and is never transmitted to zkMe, the Verifier, or any third party.
Soulbound Token (SBT) anchoring. Instead of relying on a traditional Verifiable Data Registry, zkMe anchors the anonymized proof on-chain as a non-transferable SBT, providing immutable, publicly auditable verification without exposing any personal data.
Agent delegation. In the Agent Economy, the Holder can delegate bounded authority to AI agents, allowing agents to present proofs on the Holder’s behalf within strictly defined constraints.
The Evolved SSI Roles
As an evolution of the roles needed for SSI, zkMe defines Roles with new interactions.
Issuer
In contrast to the traditional SSI concept where a single Issuer both creates and signs the credential, zkMe splits the Issuer role into two distinct functions:
Credential Issuer. Refers to governmental or financial entities or organizations that issue physical or digital credentials (such as passports, national ID cards, bank statements, or professional licenses) to individual Holders. This role is equivalent to the Issuer in the traditional SSI trust triangle. The Credential Issuer is the original source of trust: the data in the credential is trusted because the issuing authority is trusted.
ZKP Issuer. A unique concept introduced by zkMe. The ZKP Issuer is not a remote service or a third-party organization. It is a trusted issuer program that runs locally on the Holder’s device. It utilizes trusted cryptographic setups and open-source, audited algorithms to process the Holder’s credentials and generate Verifiable Presentations in the form of Zero-Knowledge Proofs.
This separation is critical for privacy. The Credential Issuer (e.g., a government) issues the raw credential. The ZKP Issuer (running on the Holder’s device) transforms that credential into a privacy-preserving proof. At no point does any remote party see the raw credential data during the proof generation process.
zkMe enables eligibility proofs: ZKPs that demonstrate the Holder meets specific criteria set by the Verifier, without disclosing the actual information itself. For example, a proof can demonstrate that the Holder:
Is above a certain age threshold (without revealing the exact date of birth)
Is a resident of a permitted jurisdiction (without revealing the exact address)
Is not on a sanctions or PEP list (without revealing the screening details)
Holds a valid financial credential (without revealing account balances)
Holder
The Holder is the individual who possesses Verifiable Credentials and uses them to access services, prove identity, or demonstrate eligibility. In zkMe’s model, the Holder maintains full custody of their credentials in an SSI Wallet (the zkMe App) and generates proofs on-demand.
Key properties of the Holder role in zkMe:
Credential custody. The Holder’s credentials are encrypted and stored locally in the SSI Wallet. They are never stored on zkMe servers or any centralized database.
Selective disclosure. The Holder chooses which claims to prove and to whom. The Verifier cannot request more information than the Holder is willing to share.
Proof generation. The Holder generates ZKPs locally on their device. The proof is mathematically bound to the specific Verifier and interaction context, preventing replay attacks.
In the Agent Economy, the Holder also acts as the Agent Principal, delegating bounded authority to AI agents via the zkVault. The delegation is cryptographically constrained: the agent can only prove specific claims, to specific targets, within a defined time window. See Agent-Ready Credentials for details.
Verifier
Verifiers are applications, smart contracts, or services that need to confirm a Holder’s eligibility without processing their personal information. The Verifier checks the cryptographic validity of the ZKP against the on-chain state (Merkle root, revocation status, expiration) and receives a boolean result: the Holder either meets the criteria or does not.
The Verifier never learns:
The Holder’s actual identity data
The specific values of the credential claims
Any information beyond what the proof is designed to reveal
In the Agent Economy, the Verifier must also perform Agent Due Diligence via zkKYA, verifying an incoming agent’s:
Regulator
The Regulator is a role unique to compliance-oriented SSI implementations. In zkMe’s model, the Regulator holds one of the key shards required to uncover a Holder’s identity in cases mandated by law (e.g., court orders, AML investigations).
The critical design constraint is that no single party can de-anonymize the Holder alone. The identity recovery process requires the collaboration of multiple key shard holders (currently a 2/2 threshold, planned expansion to 3/3). This ensures that the Regulator’s power is structurally limited: they can participate in lawful identity recovery, but they cannot unilaterally surveil or de-anonymize users.
For technical details on the threshold encryption mechanism, see zkVault.
zkMe SBT
In zkMe’s model, the on-chain representation of a Holder’s verified identity is a Soulbound Token (SBT), a non-transferable token stored on public distributed ledgers. The SBT points to decentralized storage containing the anonymized ZKPs.
In contrast to typical SSI implementations where Verifiable Credentials may be stored in a centralized registry:
Only anonymized VP claims (ZKPs) are stored; no raw personal data is ever written on-chain
Claims are explicitly designed to prevent indirect Holder identification through correlation or inference
Claims are only accessible to authorized stakeholders who hold the appropriate verification keys
The zkMe SBT contains the Holder’s DID, the ZKP, and one of the key shards used in the threshold encryption scheme that protects the Holder’s raw data.
For details on how SBTs are minted and managed, see Smart Contracts. For details on the DID specification, see DID Method.
The zkMe App: SSI Wallet
The zkMe App is the user-facing SSI wallet that implements the Holder role. It is a secure, decentralized mobile application utilizing MPC (Multi-Party Computation) cryptography for key management, ensuring that no single device or server holds the complete private key.
Core Capabilities
MPC Key Management
Private keys are distributed across multiple devices/nodes using MPC, eliminating single points of failure and reducing the risk of unauthorized access.
OCR Document Scanning
Built-in Optical Character Recognition extracts data from physical ID documents (passports, national IDs, driver’s licenses) directly on the device.
Facial Recognition
Biometric verification confirms that the user presenting the document is the same person depicted on it. The facial data is processed locally and never transmitted.
ZKP Generation
Zero-Knowledge Proofs are generated entirely on-device using the ZKP Issuer, transforming raw credential data into privacy-preserving proofs.
SBT Minting
Verification proofs in the form of Soulbound Tokens are minted from the SSI wallet onto the Holder’s asset wallet, anchoring the proof on-chain.
Sanctions Screening
Users are screened against criminal, terrorist, and PEP (Politically Exposed Person) lists as part of the credential issuance process.
The zkMe App is available at app.zk.me. For web-based integration, the same functionality is accessible via the zkMe SDK.
Last updated