Data Verification Request
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Data Verification Request (DVR) is the main zkPass module running within the framework of the zkPass Service.
The DVR application facilitates the verification of user data while maintaining its privacy. To use the DVR and participate in the DVR workflow, the DVR clients take one of the following client roles: Data Issuer, Data Holder (the user), and Proof Verifier.
The Proof Verifier sets the criteria for users to access certain services or resources. These criteria are encoded as a query script written by the Proof Verifier client, and the script represents business logic that verifies against the user's documents.
Although the user owns their data, it is typically issued and signed by a trusted entity known as the Data Issuer. The zkPass service processes the business logic specified in the DVR query script, generating a Zero Knowledge proof and the query output. The Proof Verifier then uses this proof and output to determine if the user meets the specified criteria. Throughout this process, the user’s data is never transmitted to the Proof Verifier, ensuring its privacy. The Verifier only receives the proof and the relevant output.
The high-level view of the DVR application and its clients is illustrated here.
It should be noted that with this server-centric approach, the user's sensitive input data is no longer confined to their device but is instead processed in a centralized server. This shift necessitates a degree of trust to ensure the confidentiality of the user's input. To alleviate this concern, zkPass Service runs the zkPass module, such as the DVR, within a Trusted Execution Environment (TEE). This secure and isolated environment aims to provide an additional layer of protection, safeguarding the privacy of user data while allowing for the efficient execution of DVR queries. In other words, zkPass can still protect data confidentiality through the trusted privacy model.
The diagram of the DVR for the holder-centric workflow is depicted below.
Beyond merely transferring the computational load of proof generation from the client device to the server, DVR incorporates a robust JSON-based query language (DVR Query) that empowers developers to articulate specific requirements or conditions to be applied to the user's data. This JSON query is executed within the Zero-Knowledge Virtual Machine (ZKVM), resulting in a cryptographic proof that verifies the execution has occurred exactly as intended, without any alterations.
The DVR inherits the two pivotal features from its client-side predecessor, enhancing them within its server-centric architecture:
Trusted Data Privacy By generating a cryptographic proof, DVR ensures that the underlying data remains confidential. The Proof Verifier can confirm the proof's validity without ever needing to access the original sensitive data. While the service-based approach does introduce a new set of concerns, which is the need to trust a centralized server with sensitive user data, DVR mitigates this issue by operating within a TEE. This adds an extra layer of security to maintain data integrity and confidentiality in an isolated and secure centralized computer.
Query Execution Transparency The cryptographic proof generated by ZKVM serves as an immutable record that the query has been executed faithfully, meeting all specified conditions or requirements. Unlike often rigid proof functions found in client-side implementations, DVR offers an easy-to-use JSON query language. This allows users to effortlessly adjust to varying logic to enforce data requirements or conditions.
This advanced feature set not only alleviates computational constraints but also offers a highly flexible, secure, and transparent way for developers to implement privacy-centric logic within their applications.
Transitioning from a client-centric to a service-oriented proof system, the DVR application and the zkPass Service strive to deliver a scalable, efficient framework that accommodates a wide range of devices with diverse computational resources. It does so without compromising its commitment to data privacy and transparent execution. Moreover, it incorporates a versatile JSON-based DVR query language that is adaptable to any user data schema, offering users even greater flexibility.
The DVR 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.
Depending on the application, the client of DVR 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 service or application that sets the requirements or conditions on the user data. It verifies the zero-knowledge proof, which contains the result of the requirements.
This multi-faceted trust model allows the proper flow of data and communications among the DVR stakeholder clients and ensures that the user’s confidential information remains protected and secure.
The Data Issuer only needs to follow this step for integration with the zkPass Service:
Sample codes for the Data Issuer implementation follow. Each step is explained in detail in the subsections. The code is also available on the zkpass-sdk repo, as shown here:
Providing a REST API to retrieve the user data
The Data Issuer is required to expose a REST API that facilitates secure user data token retrieval. The API should be designed to authenticate the user robustly, ensuring that only the legitimate owner can access the data. The zkPass SDK does not dictate the precise authentication mechanisms, API semantics, or response formats, providing developers the flexibility to implement an approach best suited to their application's architecture.
The Data Issuer needs to make sure the user data is in JSON encoding. The DVR app architecture does not dictate the schema or structure of the user data, however, JSON encoding is required.
By conforming to these guidelines, Data Issuers contribute to the robustness and security of the DVR app infrastructure, ensuring an optimized and secure experience for all users involved.
Signing the User Data
As the authority provisioning sensitive user data, the Data Issuer plays a critical role in the DVR ecosystem. To ensure the authenticity of the user data, the Data Issuer must sign this sensitive information into a JWS (JSON Web Signature) token. The signing of the user data by the Data Issuer is illustrated by part of the DVR/zkPass call sequence, which is highlighted in red below:
The zkpass-client SDK library provides a specialized utility method for this purpose: sign_data_to_jws_token
. How to digitally sign the user data using the zkpass-client SDK library is illustrated by the code snippet below.
Parameters passed to sign_data_to_jws_token:
ISSUER_PRIVKEY This is the signing private key owned by the Data Issuer.
json!(data) This is the user data in JSON encoding.
Some(ep) This is the Keyset Endpoint for the public key needed to verify the signed user data. If the Data Issuer does not implement the JWKS (JSON Web Key Set) endpoints, a None parameter can be passed here, meaning that the public key is distributed manually.
Understanding the DVR and its functionalities revolves around comprehending three fundamental concepts that form the backbone of the system. These concepts are integral to the operations of DVR running on zkPass Service and are crucial for anyone looking to effectively utilize or develop with this application.
The diagram below illustrates the relationship among the three:
At a fundamental level, the user data and the DVR Info, which contains the query, act as essential inputs to the DVR/zkPass. These two components are necessary for the generation of the zkPass proof.
For a more comprehensive understanding of the zkPass proof creation, examining the query processing pipeline provides insight into how this process unfolds.
Sending the ZkpassProof object to the Proof Verifier for verification
No integration with the zkpass-client SDK library is needed for this step.
Once the Data Holder receives the Zkpass Proof from the zkPass Service, it will pass it along to the Proof Verifier for verification. The Proof Verifier provides a for this purpose.
A zkPass Proof is a token that the zkPass Service generates. It is a composite of several key components.
Zero-Knowledge Proof: This is the crux of the cryptographic proof generated by executing a specific query on user data using a Zero Knowledge Virtual Machine (ZKVM), which runs within a Trusted Execution Environment (TEE). It verifies that the query has been executed correctly while keeping the underlying data confidential.
Query Output: This results from the application running on the ZKVM. This output is intended to be shared, and the Zero-Knowledge Proof guarantees its integrity.
Metadata: This includes auxiliary information about the proof from the application's perspective. In the context of DVR, they are timestamps, the unique identifier for the Data Verification Request (DVR), and other contextual data that might be necessary for auditing or verification.
The zkPass proof is constructed in a DVR pipeline of processes that start with two main inputs: User Data and the DVR Info, as illustrated here.
The zkPass Proof object is signed by the zkPass Service into a JSON Web Signature (JWS) token to ensure its authenticity and integrity. Any tampering with the proof token can be easily detected, providing an additional layer of security.
The zkPass Proof facilitates a paradigm where the Verifier does not need direct access to the original, sensitive data. The Verifier can confirm the validity of a specific claim about the data by examining the Zero-Knowledge Proof. This is particularly powerful in scenarios that require stringent data privacy controls.
The zkPass Proof isn't just about data confidentiality; it also ensures transparency in query execution. It is an immutable record, confirming that a particular query has been executed faithfully against the user data, adhering to all specified conditions or requirements.
The zkPass Proof is a robust, secure, and flexible mechanism designed to facilitate privacy-preserving data operations. It encapsulates the cryptographic proof of a query's accurate execution, the query's output, and relevant metadata, all wrapped in a secure, authenticated package. It provides a versatile and transparent way to conduct data operations while maintaining the highest data privacy and integrity standards.
Retrieving the User Data from the Data Issuer
No integration with the zkpass-client SDK library is needed for this step.
The User Data retrieves the user data that is needed by the DVR by calling the provided by the Data Issuer.
Data Verification Request Info
DVR Info is information that contains data and parameters that define the behavior of the DVR application as defined by the Proof Verifier. Each DVR Info has two main parts:
Metadata (The Envelope of the DVR) Think of the metadata as the envelope that holds the DVR. It contains:
DVR ID This is like a tracking number for the request. It helps to know which question you're dealing with. This information is mainly used by the zkPass Service.
User Data Requests A mapping containing multiple UserDataRequest, which contains the User Data URL and the Public Key
User Data URL The URL to retrieve the user data referenced by the DVR Query variables. The Proof Verifier uses this information to tell the Data Holder where to download the user data content. A Data Issuer typically hosts the URL site. Note that this information is optional. The absence of this information means that the way to determine where to get the user data is embedded in the application business logic of the Data Holder.
Public Key This public key verifies that the user's data hasn't been tampered with.
Query (The Actual Question) The real heart of the DVR is the query. This is the actual question or condition you want to check against the user's data. In zkPass, you write this query using a unique format called zkPass JSON Query Language. The query uses the concept of variables to reference elements that exist in the user data and compare the variable values with specific constant literals.
In this example query, variable "personalInfo.firstName" references the JSON element "firstName" whose parent element is "personalInfo". This element exists in the user data.
Like user data, the Digital Verification Record (DVR) must transform into a secure, two-layered cryptographic token. Here's how it works:
This dual-layer token security model ensures that only the Proof Verifier, Data Holder, and zkPass Query Host can access the DVR's content while also allowing for verification of the token's authenticity. The design also guarantees that the DVR can be safely transmitted; unauthorized parties won't be able to modify or read the token as it moves through the network toward its final destination at the zkPass Service.
So, a DVR Info is a two-part package:
Metadata tells you which DVR you're dealing with and makes sure the user data is verifiable
Query specifies what you want to know about the user's data
By understanding these parts, you can use DVR Query language to ask all sorts of specific questions about user data in a secure and organized way.
Calling zkPass Service's generate_zkpass_proof REST API to create the ZkPass Proof
User data encapsulates a spectrum of sensitive and confidential attributes, credentials, or claims, ranging from driver's licenses and passports to financial credentials such as bank account details.
The user data is modeled after the , which are structured pieces of information associated with a particular subject. Unlike the Verifiable Credentials, which adhere to rigorous and complex formatting standards, our user data model offers flexibility. It's engineered to accommodate any user data schemas, including the Verifiable Credentials.
In the app architecture, the individual or system who actually owns the data is referred to as the Data Holder or User. However, this data is initially provided by another party, known as the Data Issuer.
One of the standout features of zkPass is its adaptability to various data structures. The framework is designed to be "schema-agnostic," meaning it doesn't impose a specific schema on the data. This flexibility allows the Data Issuer to work with different types of data structures seamlessly.
For Data Issuers, the only requirement is that the data should be encoded in JSON format. This standardization enables easy integration into the zkPass workflow without necessitating specific data schematization.
At the end of the data flow, the consumer of this user data is the DVR app which is running inside the zkPass Host. This component operates in a secure and isolated environment, ensuring the integrity and confidentiality of the user data being queried.
In the context of secure data transmission, the user data content needs to be encapsulated within a multi-layered cryptographic token for confidentiality and integrity. Specifically, this token consists of two nested layers:
This double-layered security ensures that the user data remains confidential and accessible only by authorized components during transit.
By employing this nested-token architecture, the user data can be securely transmitted through the network. Only the Data Issuer, Data Holder, and zkPass Host are allowed to access the user data's content. This not only maintains the confidentiality and integrity of the user data but also prevents unauthorized parties from tampering with or viewing the token during its transit to the zkPass Service.
Retrieving the Data Verification Request (DVR) from the Proof Verifier
No integration with the zkpass-client SDK library is needed for this step.
The Data Holder first gets the DVR by calling the provided by the Proof Verifier.
Part of the zkPass call sequence diagram, which corresponds to the DVR retrieval step, is illustrated below.
Inner Token (for signing) This is the DVR data that gets signed by the Proof Verifier into a token. The signing ensures that the token's authenticity can be later verified. The signed DVR token is typically sent from the Proof Verifier to the Data Holder. Once received by the Data Holder application, the user can still view the content of the DVR for visual verification of what the query intends to check on the user data.
Outer Token (for encrypting) This is the previously signed DVR token which has been encrypted into a JSON Web Encryption (JWT) token by the Data Holder application. Prior to sending the signed DVR token to the zkPass Service, the Data Holder encrypts the token again by wrapping it with a token. This is to ensure that only the zkPass Query Host process (a critical component inside the zkPass Service), which runs in the Trusted Environment Environment (TEE), can decrypt and view the DVR's content while the data is in transit.
Inner Token (for signing) This is the user data that gets signed by the Data Issuer into a token. This digital signature guarantees that the token's origin and integrity can be verified at a later stage. Typically, this signed token is then transmitted from the Data Issuer to the Data Holder. Upon receipt, the Data Holder's application allows the user to visually inspect the content of their data. This ensures transparency while maintaining the token's secure and authenticated state.
Outer Token (for encrypting) The user data token, initially signed by the Data Issuer, undergoes another layer of security before it's sent to the zkPass Service. The Data Holder's application encrypts this signed token into a format. The reason for this additional encryption is to restrict access to the token's content while it's being transferred. Specifically, only the DVR app running in the zkPass Host process—a key component within the zkPass Service that operates in a Trusted Execution Environment (TEE)—is authorized to decrypt and view the content of the user data.
DVR defines a JSON query language that allows the Proof Verifier to check if the user has data that meets specific requirements, conditions, or constraints.
The query language is implemented by the DVR Query Engine component, which takes two inputs:
User Data This is the JSON data that is issued by the Data Issuer and is being inquired by the Proof Verifier to see if the data meets specific requirements or conditions. The data can follow any schema or structure as DVR does not set any specific format requirement on the user data.
DVR Query The query is a JSON-based script that sets the requirements or conditions for the user data. The query is expressed as a DVR scripting language and is included in the "query" field of the Data Verification Request (DVR) object. An example of the query would be “user must be either married or over 21 years of age”. The query is executed by the DVR Query Engine to produce the ZK Proof and the result of the query.
The goal of defining its own query language is to let the Proof Validator client be able to perform queries on the data using an expressive, flexible, intuitive, easy-to-use, and performant scripting language.
The following are the supported basic data types by the DVR Query language:
Integer A signed 64-bit integer data type. Example: 10, -12
String A sequence of characters. Example: "Hello, world!"
Boolean A binary value that can be either true or false
The list of supported operators:
Boolean Operators:
or
and
Relational Operators: >, >=, <, <=
Applies to integer
Equality Operators
Equality operator: == Applies to boolean, integer, and string. In the case of a string, this is a case-sensitive comparison.
Inequality operator: != Applies to boolean, integer, string
String-specific Relational Operations
~!= Case-insensitive inequality operation on a string
~== Case-insensitive equality operation on string
The zkPass Query language also defines the following concepts:
Variable The variable corresponds to the key name of the key/value json element in the query data. To reference nested elements in the json data, delimiter “.” is used as the path separator. The variable must appear on the left-hand side of a relational expression.
Literal (Constant) The constant value is compared to the variable's value. The literal must appear on the right-hand side of a relational expression. The data type of the literal must match that of the variable.
Providing a REST API to retrieve the DVR
The Proof Verifier must also define a mechanism through which users can retrieve the DVR token. The retrieval could be accomplished through various means, such as QR code scanning, a RESTful API, or other methods. zkPass SDK provides the flexibility to choose a retrieval mechanism most appropriate to the application's architectural design.
Signing the DVR data
The Proof Verifier is the entity responsible for defining the Data Verification Request (DVR) against which user data is verified. To accurately create DVR queries, the verifier must have an in-depth understanding of the user data format as provided by the Data Issuer. Utilizing zkPass Query Language, the verifier can reference specific fields within the user data using the notion of 'Variable'.
Upon receipt of a Zero-Knowledge Proof (ZKP) from the user, the verifier invokes zkPass.verifyProof function to authenticate the proof. A successful verification indicates that the user's data complies with all conditions stipulated in the DVR query.
The Proof Verifier is responsible for generating tokens for the DVR content. To achieve this, it must manage a public/private key pair specifically for digital signing. Additionally, the Proof Verifier should expose a standard JWKS (JSON Web Key Set) endpoint through a RESTful API for signature verification purposes. This endpoint serves as the source for obtaining the public key required to validate the DVR token's signature.
To facilitate the zkPass flow, the verifier must tokenize the DVR object into a JWT (JSON Web Token). In the inner token’s JWT header, the following parameters will be included by the verifier:
jku The URL where the public verification key can be retrieved.
kid The Key ID, is a unique identifier for the specific verification key in use.
In the implementation of the DVR retrieval codes, the Proof Verifier needs to digitally sign the DVR. This is done using the zkpass-client SDK library as illustrated here.
zkPass Service processes the DVR query contained in the DVR Info and the user data referenced by the query in a pipeline flow, as depicted below.
Initialization of the Data Verification Request(DVR) The proof verification begins by creating a Data Verification Request (DVR). This record is essential as it holds the specific request or "query" that needs to be verified.
Inputs for Verification There are two key pieces of information that the DVR Query Engine requires to perform verification:
The Query: This is the request for information or action that needs to be checked.
The User Data: This refers to any information related to the user that the query will use or check against.
Processing by the DVR Query Engine The DVR Query Engine is the powerhouse where the actual verification takes place. This engine operates within the Zero-Knowledge Virtual Machine (ZKVM), a secure environment designed for processing these queries.
Results of the Verification Once the query has been processed, there are two results produced:
The Zero-Knowledge Proof (ZK Proof) This is a verification result that proves the query was processed correctly without revealing any private details.
The Query Result This is the outcome of the query after it has been processed.
Packaging the Results Both the ZK proof and the query result are bundled into a single package known as the zkPass Proof object. This object can then be used to confirm the integrity and accuracy of the query process without exposing any sensitive information.
The heart of the DVR application is the query engine, which implements the DVR app. The query engine is designed as a DVR Query language interpreter that runs on the ZKVM directly.
DVR Query Engine Codes The core component, the DVR Query Engine, is programmed in the Rust language. Rust is known for its safety and performance, making it an excellent choice for building reliable and secure systems.
Compilation to Assembly Code To integrate with the Zero-Knowledge Virtual Machine (ZKVM), the DVR Query Engine is compiled into assembly code. This compilation is done using a specialized set of tools known as the compiler toolchain, which is specifically designed for the ZKVM environment. This ensures that the Query Engine is compatible with the security and operational requirements of the ZKVM.
Build Outputs After the compilation process, two primary outputs are generated:
The Zero-Knowledge Proof Generator (ZK Proof Generator) This module is responsible for creating cryptographic proofs that confirm the validity of a query without revealing any underlying data. It is an integral part of the DVR Query Engine.
The Zero-Knowledge Proof Verifier (ZK Proof Verifier)
This is the counterpart to the Proof Generator. It is tasked with checking the validity of the proofs generated by the Proof Generator. The Proof Verifier is included in the zkpass-client
library, allowing client applications to verify proofs independently.
The Proof Verifier should take these two steps for the integration with zkPass:
A sample implementation for a proof verifier is provided on the zkpass-sdk repo, as shown here:
The DVR app distinguishes itself with its adaptable workflows, specifically tailored to suit different business contexts. The platform supports two primary workflows: Holder-Centric, ideal for B2C (Business-to-Client) scenarios, and Verifier-Centric, suited for B2B (Business-to-Business) environments. Understanding how these workflows operate and their applicability can greatly enhance the effectiveness of DVR in various settings.
In a B2C setting, where businesses interact directly with individual clients or customers, the Holder-Centric workflow is particularly effective. Here, the Data Holder (the client or customer) initiates the data verification process by requesting a Data Verification Request (DVR) from the Proof Verifier. This approach empowers the individual, allowing them to control how and when their data is verified, aligning perfectly with customer-centric business models where individual agency and privacy are paramount.
Conversely, in a B2B context, the Verifier-Centric workflow becomes more relevant. In this model, the verification process starts with the Proof Verifier, usually a business, sending the DVR directly to the Data Issuer. This workflow is suitable for situations where businesses need to establish or verify partnerships, credentials, or compliance among other businesses. The verifier-centric approach offers a streamlined and efficient method for regular or systematic verifications, which is common in business-to-business interactions.
DVR's capability to support both holder-centric and verifier-centric workflows provides a significant advantage in catering to a wide range of customer needs. Whether it’s a business dealing with individual clients or other businesses, DVR offers a tailored approach to data verification. This flexibility ensures that the platform is not only versatile but also highly relevant and efficient in various real-world applications.
In summary, the dual workflow approach of DVR – holder-centric for B2C and verifier-centric for B2B – showcases the platform's versatility and adaptability to different business models. By understanding and utilizing these workflows appropriately, organizations can maximize the benefits of DVR, ensuring a seamless, secure, and user-friendly experience in their data verification processes.
For successful integration into the DVR application workflow, each client stakeholder is advised to follow the guidelines specified in this documentation.
The call flow involving all stakeholders within the DVR application is depicted in the accompanying diagram below.
The call sequence diagram for the interaction is provided here.
The comprehensive workflow for zkPass is elaborated in the following sections, where each step is explained in detail.
Step 1:
Call get_dvr_token (Part A)
To initiate the process, the Data Holder invokes the get_dvr_token
API method provided by the Verifier. This call necessitates authentication to enable the Proof Verifier to securely ascertain the identity of the requesting user.
Note: The API signature and payload format for get_dvr_token
are determined by the specific implementation of the Proof Verifier. zkPass does not impose any particular specifications or structure.
Return the DVR token (Part B) Upon receiving the request, the Verifier constructs the DVR, tailoring the query according to requirements specific to the user's core data. For a concrete example of a DVR query, please refer to this example.
The Verifier ensures the uniqueness of the DVR by generating a distinct DVR ID each time a new DVR is created. After the DVR is assembled, the Verifier signs and encapsulates it in a JSON Web Signature (JWS) token to affirm its integrity and authenticity.
Step 2:
Call get_user_data_token (Part A)
Once the DVR token is obtained, the Data Holder moves on to gather the user data specified by the DVR requirements. This is achieved by invoking the get_user_data_token
API method offered by the Data Issuer. Like the earlier call to the Verifier, this request also mandates authentication.
Caching Consideration: If the requisite user data is already cached by the Data Holder and is still valid (not expired), this API call can be skipped. In such cases, proceed directly to Step 3.
Note: The API signature and payload structure for get_user_data_token
are specific to the Data Issuer's implementation. zkPass does not prescribe any particular format or details.
Return the User Data token (Part B) Upon validating the request, the Data Issuer locates the corresponding user data. It then signs and serializes this data into a JSON Web Signature (JWS) token to confirm its authenticity. Finally, the JWS token encapsulating the user data is returned to the requesting Data Holder.
Step 3:
Call generate_zkpass_proof (Part A)
Upon securing both the DVR token and the user data token, the Data Holder invokes the generate_zkpass_proof
method from the zkclient-lib
. This method takes both tokens as input parameters, encryptes both tokens into JWE tokens, and serves as a wrapper for a RESTful API call to the zkPass Service. The core objective of this invocation is to execute the query defined in the DVR against the supplied user data, subsequently generating both the Zero-Knowledge Proof and the query output.
Return the ZkPass Proof token (Part B)
The zkPass Service handles the generate_zkpass_proof
request by validating the signatures on both input tokens and decrypting them. The query is then executed within a secure, isolated environment—specifically, the zkPass Query Host process running inside a Trusted Execution Environment (TEE).
Upon successful execution, the zkPass Service constructs a zkPass Proof object. This object encapsulates the query output and is signed into a JWS token for authenticity. The zkPass Proof token is then returned to the calling Data Holder.
zkPass Proof Components: The zkPass Proof object comprises the cryptographic Zero-Knowledge Proof, the output of the executed query, and associated metadata about the proof itself.
Step 4:
Call verify_zkpass_proof (Part A)
At this point, the Data Holder possesses the zkPass Proof token. It then proceeds to call the Verifier's verify_zkpass_proof
method, supplying the proof token as the sole input parameter.
Note: The API signature and payload schema for the Verifier's verify_zkpass_proof
method are implementation-specific. zkPass does not impose any standardized format or details.
Verify the ZkPass Proof (Part B)
Upon receipt of the request, the Verifier scrutinizes the signature attached to the proof token. Subsequently, it invokes the verify_zkpass_proof
function available in the zkpass-client library. This function performs the ZKP verification on the cryptographic seal produced by the ZKVM running in the zkPass Query Host process. It also extracts the query output from the seal.
Return the query result (Part C) After successfully validating the zkPass Proof and extracting the query output, the Verifier relays the query result back to the Data Holder. This final step completes the zkPass workflow.