Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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:
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.
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.
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 REST API for this purpose.
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.
Calling zkPass Service's generate_zkpass_proof REST API to create the ZkPass Proof
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.
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.