👥zkPass Client Roles
zkPass follows a robust trust model inspired by the W3C Decentralized Identifiers (DID) standards. Within the zkPass ecosystem, we define three client roles which participate in the zkPass ecosystem.
Last updated
zkPass follows a robust trust model inspired by the W3C Decentralized Identifiers (DID) standards. Within the zkPass ecosystem, we define three client roles which participate in the zkPass ecosystem.
Last updated
Depending on the application, the client of zkPass can take one of these roles:
Data Issuer The entity responsible for issuing the original data that requires protection.
Data Holder (User) The individual whose confidential data is being protected.
Proof Verifier The Proof Verifier is the client that is responsible for setting conditions and requirements on user data using the zkPass Query language, which are then encapsulated in a Data Verification Request (DVR). The concept of a Proof Verifier is similar to that of the DID's Data Verifier. Unlike a generic DID's Data Verifier, the Proof Verifier specifically validates zero-knowledge proofs generated from the query execution to ensure the user data meets the specified conditions. The term "Proof Verifier" is therefore used here to emphasize its specialized capability for verifying data through zkPass Proofs.
This multi-faceted trust model allows the proper flow of data and communications among the zkPass stakeholder clients and ensures that the user’s confidential information remains protected and secure.
Central to the ecosystem is the zkPass service, which provides the generateProof RESTful API. This method takes the user data token and the dvr token, both of which are signed and encrypted JWT content. This is a nested JWT message in which the inner token is the signed JWT (JWS), and the outer token is the encrypted JWT (JWE). The caller of the API first signs the inner token with its signing private key and then encrypts the outer token with the zkPass service’s public key. Upon receiving the user data and dvr tokens, zkPass service first decrypts the outer token with its private key and then verifies the signature of the inner token with the public of the caller. Since the public key of the zkPass must be known to the caller of the API, zkService exposes the JWKS endpoint, which contains the URL and the key name for its public key.
