User Data

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 W3C's Verifiable Credentials, 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 DVR 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.

Schema-Agnostic Design

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.

Data Encoding Requirements

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.

Secure Data Consumption

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.

Signing and Encrypting User Data

The layering of JWE and JWS on User Data

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:

1. Inner Token (for signing) This is the user data that gets signed by the Data Issuer into a JSON Web Signature (JWS) 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.

2. 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 JSON Web Encryption (JWE) 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.

   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.