zkPass Integration

Car Loan Screening Workflow with zkPass Integration

To achieve full integration with the zkPass framework, all key stakeholders must adhere to the SDK integration guidelines. In the context of the car loan screening process, there are three primary parties involved, as detailed below.

• BCA Bank (Data Issuer) BCA Bank assumes the role of the Data Issuer, as specified by the zkPass framework. In this capacity, the bank defines the attributes encapsulated within the "BCA Customer Profile," as previously described. Thanks to the format-agnostic nature of zkPass concerning user data, the articulated "BCA Customer Profile" is fully interoperable with the zkPass Service. This provides substantial flexibility for the Data Issuer, enabling it to work seamlessly with any data schema or format for its user data.

• BCA Finance (Proof Verifier) Taking the Proof Verifier role within the context of the zkPass framework, BCA Finance defines the criteria for the "Loan Screening" Data Verification Request (DVR). This DVR encapsulates the eligibility requirements established by BCA Finance for assessing car loan applications. Before generating the DVR, BCA Finance has already ascertained the applicant's identity through alternative mechanisms, such as manual verification or AI-based OCR scanning. Having acquired and validated the applicant's full name and driver's license number, this data serves as a cross-referential check against the customer profile to ensure its attribution to the correct individual.

• My BCA (Data Holder) Developed by BCA Bank, the "My BCA" mobile application serves as the main tool for account holders to access a multitude of banking features. This application represents the “User”, also called the “Data Holder,’ role in the zkPass ecosystem. In the zkPass workflow, the Data Holder is usually the user who is interested to answer or resolve the query posed by the Proof Verifier. My BCA is designed to securely retrieve customer profile data from BCA Bank's backend databases, implementing stringent authentication protocols to ensure that only authorized account holders gain access to sensitive information. The application collects the “Loan Screening” DVR from BCA Finance, and the user’s “BCA Customer Profile” from BCA Bank, and relays the information to zkPass Service to create the ZK proof for the loan eligibility.

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 "Loan Screening" token

Ramana launches the "My BCA" application to obtain a "Loan Screening" token from BCA Finance. This token serves as a Data Verification Request (DVR) specifically for "Loan Screening" and comes in the form of a JSON Web Signature (JWS) token, cryptographically signed by BCA Finance.

Step 2: Acquiring the "BCA Customer Profile" token

The "My BCA" application also retrieves a "BCA Customer Profile" token from BCA Bank. Like the earlier step, this token encapsulates the "BCA Customer Profile" user data. To guarantee its authenticity, it is cryptographically signed into a JSON Web Signature (JWS) token by BCA Bank.

Step 3: Calling the zkPass Service REST API

The "My BCA" application calls the zkPass Service'sgenerate_zkpass_proof REST API, using the previously acquired "Loan Screening" and "BCA Customer Profile" tokens as input parameters. This API request aims to create a zkPass proof, which is generated according to the query outlined in the "Loan Screening" Data Verification Request (DVR). This query is executed against the data in the "BCA Customer Profile."

Upon receiving the API request, the zkPass Service processes the call, generates the zkPass proof, and returns it to the "My BCA" 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 processing the zkPass Proof, zkPass Service returns the proof to My BCA app.

Step 5: Calling the Verifier to verify the proof

The "My BCA" application calls the Verifier (BCA Finance), passing the received zkPass Proof for verification.

Step 6: Verifying the zkPass Proof and getting the query result

BCA Finance validates the zkPass proof and extracts the query result, which could either be true or false. At this point, BCA Finance determines whether Ramana Maharshi has passed the loan screening process, and it an return the result of the query to the Data Holder (My BCA App). This completes the entire zkPass data flow.

All of the three stakeholders above, BCA Bank, My BCA app, and BCA Finance, are essentially the client components of the zkPass framework. Each client uses the zkpass-client library to interact with the ecosystem, as illustrated by the diagram.

As depicted above, BCA Bank circumvents direct access from external organizations to the user's exhaustive customer profile, which comprises various personal and sensitive attributes irrelevant to the car loan assessment. Instead, BCA Finance must outline the criteria in the "Loan Screening" Data Verification Request (DVR), which the "My BCA" app subsequently fetches. Upon collecting the user data and the DVR, the app employs the zkPass Service to generate proof. This proof, stripped of any personally identifiable information (PII), constitutes the sole data payload transmitted to BCA Finance, thereby preserving the privacy of BCA's customers.

Moreover, an implicit trust relationship exists between BCA Finance and BCA Bank, as demonstrated. BCA Finance relies on the assumption that the data encapsulated within the user's BCA Customer Profile is both accurate and verifiable.