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.
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:
Inner Token (for signing) This is the DVR data that gets signed by the Proof Verifier into a JSON Web Signature (JWS) 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 JSON Web Encryption (JWE) 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.
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.
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.
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.
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.
