Vision, Mission & Design Philosophy
An innovative Identity Layer protocol that enhances the Self-Sovereign Identity (SSI) model by integrating Verifiable Credentials (VCs), Verifiable Presentations (VPs), Zero-Knowledge Proofs (ZKP), Decentralized Identifiers (DIDs), and Soulbound Token (SBT). zkMe prioritizes privacy-by-design, decentralization, regulatory compliance, and transparency to create a comprehensive and secure user experience.
Vision & Mission
+ Vision
To build the zk-Identity layer of web3. In the trust-less world of tomorrow, credentials are only shared when, where and strictly as irreducibly needed.
+ Mission
We build the leading infrastructure for presenting verified Identity Credentials & Data in a trustless and private manner. Issuers, Holders and Verifiers around the world trust and employ the zkMe Network to leverage Identities' economic value.
Design Philosophy
1. Core Concept
zkMe is a comprehensive solution to implement privacy, decentralization, compliance, and transparency in credential networks. Its emphasis end-to-end zero-knowledge processing, and selective information disclosure. Self-Sovereign Identities (SSI) provides users with a high degree of control over their personal data. The platform's compliance with existing and upcoming regulations ensures that it can be used in all industries, ranging finance, to gaming, travel, or even social media.
zkMe follows a privacy-by-design approach above all else in order to guarantee that personal data is processed fully automatically and directly on end devices or within a decentralized oracle network. This ensures that no party can access personally identifying information, and personal data is shared only when absolutely necessary. Users maintain complete control over their information, with the ability to revoke verification permissions on a project-by-project basis via their mobile phones.
zkMe is committed to decentralization. All trust-building determinations and computations are managed by a decentralized network of node operators, minimizing the risk of protocol manipulation and eliminating reliance on proxy verifications. Furthermore, zkMe is party-agnostic, ensuring that no role in the infrastructure is permanently fixed or controlled by a single entity.
zkMe is both transparent and open source. All algorithms necessary for running the infrastructure undergo regular audits and are made available to the ecosystem for the development of additional credential use cases. The platform can process and cross-pollinate credentials across all identity silos, empowering users to benefit from credentials linked to their web3 identities, as well as their real-life or web2 Identities.
zkMe takes the W3C open standard approach of Verifiable Credentials (VCs) and the “Triangle of Trust”, and expands on it by:
Removing the Issuer trust assumption by replacing the centralized Issuer with open-source, trustless zero-knowledge verification algorithms.
Removing the trust assumption in bridging credentials across (chain-) ecosystems through the use of a MPC Oracle.
Increasing the on-chain availability and reusability of VCs by storing anonymous, zero-knowledge proof presentations (ZKP VPs) on-chain in form of non-transferable, non-fungible tokens (SBT).
Decentralizing (and removing the trust assumption) into the Verifiable Data Registry by hosting anonymous proofs on decentralized storage.
2. Leading Design Considerations
2.1 Compliance
zkMe Identity Oracles are designed with regulatory compliance in mind, adhering to FATF’s 2019 recommendations for crypto KYC/AML compliance (incl. travel rule requirements), EU’s 6AML and TRF directives, and even upcoming EU MiCA and US Lummis-Gilibrand bill requirements while fulfilling international W3C DIDs, VC, and VP standards. Allowing both front ends and smart contracts to enforce due diligence requirements.
2.2 Interoperability
zkMe Identity Oracles are designed with interoperability and composability in mind; ensuring that credentials attested to once can be consumed (verified) on any chain. Perspectively, any role within the zkMe Identity Layer can be operated by any party and not tied to zkMe Technology Limted as a company, making the solution chain and role agnostic.
Omni-Chain
Chain-Agnostic
Role-Agnostic
2.3 User Experience
zkMe Identity Oracles are designed to enable the highest degree of user experience
Credential Reusability
Conversion Rate
Mobile First
Self-Sovereignty
2.4 End-to-End Zero-Knowledge
No Unilateral PII Access
No Data Sharing
No Indirect Identification
Verifiable End-to-End
3. High Level Process Flow
3.1 Main Process
3.1.1 Credential Creation
The Holder presents the off-chain credential to an open-sourced verification algorithm that runs locally on the Holder’s end user device (mobile phone). The verification algorithm encodes the results of the verification algorithm through anonymized, tamper-proof ZKPs. The ZKPs are sent to an MPC node Oracle for verification of the proof consistency. Once verified, the MPC node Oracle calls a Mint Smart Contract that creates a credential proof SBT onto the Self-Sovereign Identity Wallet of the Holder.
3.1.2 Proof Generation
3.1.3 Proof Verification
3.1.3 Proof Delegation
The Holder delegates the credential proof to any chain ecosystem he/she is active in, by signing a delegation transaction from the SSI-Wallet. This calls a Delegate Smart Contract that bridges the SBT onto the chain ecosystem of choice.
3.1.4 Credential Attestation
The Holder accesses the Service provided by the Verifier by connecting his/her wallet. Depending on the requirement background, the Verifier can either call a Verify or a Certify smart contract to ascertain the eligibility of the Holder. The Verify smart contract allows for a one-time verification (yes/no answer to a ZKP encoded eligibility question) of the Holder credential. The Certify smart contract additionally allows to keep an auditable proof that a verification of the Holder by the Verifier took place and the Regulator may initiate bad actor proceedings against the Holder. Invoking a “certification” requires an additional signature approval by the Holder.
Note: Tasks 3.1.1 through 3.1.3 can be skipped in case the Holder is reusing a Credential verified previously.
Last updated
