# zkPass Client Roles

<div align="left"><figure><img src="/files/wbq1KiM7i065x4YKdmRO" alt="" width="563"><figcaption><p>The Three zkPass Client Roles</p></figcaption></figure></div>

Depending on the application, the client of zkPass can take one of these roles:

1. <mark style="color:orange;">**Data Issuer**</mark>\
   The entity responsible for issuing the original data that requires protection.
2. <mark style="color:orange;">**Data Holder (User)**</mark>\
   The individual whose confidential data is being protected.
3. <mark style="color:orange;">**Proof Verifier**</mark>\
   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.

<figure><img src="/files/jcDsjTFSMAc1XWUbAEtn" alt=""><figcaption></figcaption></figure>

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.

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://gl-docs.gitbook.io/zkpass/core-components/zkpass-client-roles.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
