Skip to main content

System flow

ZUNI arch As illustrated in figure above, the ZUNI incorporates several roles and components as further explained below:

  • The architecture diagram for verifying electronic certificates using ZKP and DID involves three main entities: issuers, verifiers, and holders. Additionally, a Verifiable Credentials Repository (VCR) is included in the architecture to handle tasks such as creating Solana wallets, registering DIDs, storing and anchoring the hash of issued VCs on the blockchain, and verifying identities and VC validity.

  • Every participant in the Zuni system must have at least one DID, which serves as a unique identifier for managing individual identities and their resources in the decentralized world. A person/organization can have multiple DIDs for different purposes, for example: education, entertainment, ... but all of these DIDs can refer to a private identity if the identity have credentials to prove that.

  • Issuers play a pivotal role in generating VCs and issuing them to relevant parties (see 1a arrow). By default, the content of VCs is hidden from the public, ensuring visibility only to the issuer and the holder. This level of privacy is achieved through the use of public key encryption methods. Each e-certificate is associated with a unique DID, registered in the Verifiable Credential Registry. Furthermore, issuers store and anchor the hash of the issued VCs to facilitate efficient management and potential revocation if required (see 1b arrow).

  • To indirectly prove that holders possess specific claims without revealing all the details of the verifiable credential, Zero-Knowledge cryptography schemes are employed. These schemes utilize a claim from a verifiable credential to derive a presented value, which is cryptographically asserted in such a way that verifiers can trust the value if they trust the issuer. The presented value represents the information that the verifier seeks to verify, along with certain public fields of the VC that enhance the verifier's confidence in the presentation of the VC (see 2 arrow). These verification details are included in a verification schema which is built by the verifier and sent to the holders for them to submit their credentials.

  • For authentication, holders must provide comprehensive certificate information, submitted to the ZK engine as raw (decrypted) data. The ZK engine then utilizes this data to generate a Zero-Knowledge proof (see arrow 3), providing evidence that the certificate is signed by the issuer without revealing any details about the signature or original data. Holders can then send the claim to the verifier (see arrow 4), including the Zero-Knowledge proof and the specific information they intend to reveal (e.g., name and other non-sensitive fields). Finally, the verifier can verify the correctness of the claim using snark-based utility (see arrow 5). Optionally, the verifier may choose to store verified VCs within their own database or on a decentralized platform.

  • Each participants can choose some set of DIDs in the network that they trust to efficiently filter out the irrelevant submissions to their verification schemas, for example: the goverment, world organizations, celebrities, ... We call this trusted DID. These trusted DIDs can form a web of trust system.

  • For efficiency, VCs are created based on credential templates. These templates can be created and used by anyone to issue credentials to others. There are some templates that can be the standard templates for popular credential types, such as KYC credential template, Driving license credential template, ... This template mechanism can help verifiers to easily pick the fields to set conditions and requirements.

    • Also, we are forming a new concept of template inheritance, in which people could extends standard templates (common standards) to build their own custom templates, which is really useful in case some issuers want to have some custom fields but still comply with the common standards. This also help VC verification process more general and a verification schema can specify the common standard to verify common fields, no matter what exactly templates are used on VCs of submitters.

  • The Zuni system also implements the Trustless Relayer, supporting data storage and transfer between entities and processes within the system. The Trustless Relayer ensures that all private data is protected by cryptography protocols before being sent to or through it, preserving data privacy and preventing interference. Moreover, the Trustless Relayer enhances data availability and removes censorship by leveraging public decentralized data storage alternatives.