# DVR Info

## <mark style="color:blue;">DVR Info</mark>

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:

1. <mark style="color:orange;">**Metadata (The Envelope of the DVR)**</mark>\
   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.&#x20;
     * Public Key\
       This public key verifies that the user's data hasn't been tampered with. <br>
2. <mark style="color:orange;">**Query (The Actual Question)**</mark>\
   \&#xNAN;*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.&#x20;

<details>

<summary>Example Query</summary>

```json
[
  {
    assign: {
      employee_onboard: {
        and: [
          { "==": [{ dvar: "bcaDocID" }, "DOC897923CP"] },
          { "~==": [{ dvar: "personalInfo.firstName" }, "Ramana"] },
          { "~==": [{ dvar: "personalInfo.lastName" }, "Maharshi"] },
          {
            "~==": [{ dvar: "personalInfo.driverLicenseNumber" }, "DL77108108"],
          },
          {
            ">=": [{ dvar: "financialInfo.creditRatings.pefindo" }, 650],
          },
          {
            ">=": [
              { dvar: "financialInfo.accounts.savings.balance" },
              55000000,
            ],
          },
        ],
      },
    },
  },
  { output: { result: { lvar: "employee_onboard" } } },
]
```

</details>

In this example query, variable *"personalInfo.firstName"* references the JSON element *"firstName"* whose parent element is *"personalInfo"*. This element exists in the user data.

## <mark style="color:blue;">Signing and Encrypting DVR</mark>

<div align="left"><figure><img src="/files/MBeFWl8XmnKMWP5KKGtD" alt="" width="375"><figcaption><p>The layering of JWE and JWS on DVR</p></figcaption></figure></div>

Like user data, the Digital Verification Record (DVR) must transform into a secure, two-layered cryptographic token. Here's how it works:

1. <mark style="color:orange;">**Inner Token (for signing)**</mark>\
   This is the DVR data that gets signed by the Proof Verifier into a [JSON Web Signature (JWS)](https://datatracker.ietf.org/doc/html/rfc7515) 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.
2. <mark style="color:orange;">**Outer Token (for encrypting)**</mark>\
   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)](https://www.rfc-editor.org/rfc/rfc7516) 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.

## <mark style="color:blue;">Summary</mark>

So, a DVR Info is a two-part package:

1. <mark style="color:orange;">**Metadata**</mark>\
   tells you which DVR you're dealing with and makes sure the user data is verifiable
2. <mark style="color:orange;">**Query**</mark>\
   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.


---

# 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/zkpass-developers-guide/zkpass-modules/dvr/key-concepts/dvr-info.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.