zkPass Integration
For seamless integration with the zkPass framework, every key stakeholder should follow the SDK integration guidelines. Within the scope of the employee onboarding scenario, there are three main parties engaged, as elaborated below.
QualityHealth Labs (Data Issuer) The lab takes the Data Issuer role as defined in the zkPass SDK. The lab defines user data as the blood test result with the above JSON content. The zkPass SDK supports any format of the user data. Therefore, the above definition of the “Blood Test Result” user data can work with the zkPass Service.
My Namaste App (Data Holder) This is the mobile app used by the new employee of Namaste Tech required to take a blood test. The mobile app takes the role of the Data Holder on behalf of the user. The app securely retrieves the blood test result from the clinic and the "Employee Onboarding" DVR from Namaste Tech. It then talks to the zkPass Service to create the zkPass proof.
Namaste Tech (Proof Verifier) This is the Proof Verifier role defined in the zkPass SDK. Namaste Tech defines the “Drug Screening DVR”, which contains the query to be executed on the blood test data. Namaste Tech is interested in receiving the zkPass proof to determine if the user has passed the drug screening test.
The following diagrams illustrate interactions among the three zkPass clients.
Interaction Flow in zkPass Clients: A Six-Step Process
The following section outlines the six key steps involved in the interaction between zkPass clients. Each step corresponds to the numbered arrow in the diagram and is elaborated here for clarity:
Step 1: Collecting the "Employee Onboarding" token
Jane Doe starts the "My Namaste" application to retrieve the "Employee Onboarding" token from Namaste Tech. This token is essentially a Data Verification Request (DVR) for "Employee Onboarding," which has been cryptographically signed by Namaste Tech into a JSON Web Signature (JWS) token.
Step 2: Acquiring the "Blood Test Result" token
The "My Namaste" application further fetches a "Blood Test Result" token from QualityHealth Lab. Similar to the previous step, this token represents the "Blood Test Result" user data and is signed into a JWS token by QualityHealth Lab.
Step 3: Calling the zkPass Service REST API
The "My Namaste" application invokes the generate_zkpass_proof REST API provided by zkPass Service with the retrieved "Employee Onboarding" token and the "Blood Test Result" token as the input parameters. This API call is made to generate a zkPass proof based on the query specified in the "Employee Onboarding" DVR, which is executed against the "Blood Test Result" data.
Upon receiving the API request, the zkPass Service processes the call, generates the zkPass proof, and returns it to the "My Namaste" application. The zkPass proof contains:
The cryptographic proof that the query has been executed properly as-is without any code modifications
The output or result of the query
Step 4: Returning the zkPass Proof to the Data Holder
After completing the processing of the zkPass Proof, zkPass Service returns the proof to the My Namaste app.
Step 5: Calling the Verifier to verify the proof
The "My Namaste" application calls the Verifier (Namaste Tech) site, passing the received zkPass Proof for verification.
Step 6: Verifying the zkPass Proof and getting the query result
The Verifier (Namaste Tech) validates the zkPass proof and extracts the query result, which could either be true or false. At this point, Namaste Tech determines whether Jane Doe has passed the drug screening test, and it can return the result of the query to the Data Holder (My Namaste app), which completes the entire zkPass data flow.
Confidentiality Note
It's crucial to emphasize that Namaste Tech never gains access to Jane Doe's actual blood test results, which contain sensitive and confidential information irrelevant to drug screening. Instead, what Namaste Tech receives is merely the zkPass proof, encompassing the cryptographic proof of query execution and its output, devoid of any confidential information about Jane Doe.
Last updated
