Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Krisna's service takes on the responsibility of formulating the "ShopSphere Account Holder" Data Verification Request (DVR), which serves as the benchmark for validating "ShopSphere ID Token" user information. In the zkPass ecosystem, the Krisna service takes the role of the Proof Verifier. To craft precise DVR queries, Krisna needs a comprehensive grasp of the data structure of the ShopSphere ID Token, as specified by the ShopSphere OIDC Provider. By employing the zkPass Query Language, Krisna is able to target particular fields within the user data through the concept of 'Variable'. Key guidelines for integration consist of the following two main steps:
The Krisna service needs to provide a RESTful API that allows for the secure retrieval of DVRs. This API must be equipped with strong user authentication measures to ensure that only the rightful owner can access their data. While zkPass doesn't specify the exact methods for authentication, the semantics of the API, or the formats of responses, it offers developers the freedom to create their own implementation. Generally, this API is used by the Data Holder as a starting point in the data verification process.
Signing the DVR
To support the smooth functioning of the zkPass process, the Krisna service is required to sign the "ShopSphere Account Holder" DVR object into a JWS (JSON Web Signature) token. To make this task easier, the zkpass-client SDK library offers a function specifically designed to streamline the signing process.
In addition, the Krisna service needs to provide the necessary public key that allows for the verification of the signed DVR. This distribution can be handled either manually or through an out-of-band method, or more efficiently, through a programmatic API call, as outlined by the JSON Web Key Set (JWKS) protocol.
After the ShopSphere app obtains the zkPass proof from the zkPass Service, it will send this proof to the Krisna service for validation. This is accomplished by the app using a proof verification API offered by the Krisna service. Similar to other aspects of zkPass, the specific methods for authentication, the design of the API, and the response formats are not rigidly defined by zkPass, allowing developers the flexibility to tailor their own implementations.
To process this verification request, the Krisna service will employ the verify_zkpass_proof
function, which is a part of the zkpass-client SDK library. This function is designed to efficiently handle the verification of the zkPass proof.
By adhering to these guidelines, Krisna reinforces the overall security and effectiveness of the zkPass ecosystem, thereby providing a reliable and secure means of data verification.
Here are the two simple steps that the ShopSphere OIDC Provider, which takes the Data Issuer client role, must implement:
The ShopSphere OIDC Provider is required to expose a RESTful API that facilitates secure user data retrieval. The API should be designed to authenticate the user robustly, ensuring that only the legitimate owner can access the data. zkPass does not dictate the actual authentication mechanisms, API semantics, or response formats, providing developers the flexibility to implement the API. The API will be typically called by the Data Holder to download the user data needed by the query specified in the DVR.
Signing the user data
To ensure seamless integration with the zkPass framework, the ShopSphere must sign this sensitive information into a JWS (JSON Web Signature) token to ensure the authenticity of the data. To this end, the zkpass-client SDK library provides a function that will simplify the signing process.
Additionally, the ShopSphere OIDC Provider must also distribute the public key needed to verify the signed user data. This can be done via manual or out-of-band public key distribution, or via a programmatic API call as defined by the JSON Web Key Set (JWKS) protocol.
Despite facing hurdles, ShopSphere continues to be steadfast in its dedication to ensuring customer privacy and fostering transparency in the evaluation of ShopSphere account holder verification, as required by Krisna, its new business collaborator.
To fulfill this commitment, ShopSphere has revamped its mobile app to incorporate the zkPass Proof-as-a-Service framework and to facilitate interactions with the Krisna app on mobile devices. A significant advantage of this integration is that ShopSphere doesn't need to alter the existing architecture or implementation of its OIDC Provider service, resulting in considerable savings in development costs. On the other hand, Krisna only needs to make minor adjustments to its login server to return the "ShopSphere Account Holder" DVR upon successful login. Additionally, Krisna must update its mobile app to launch the ShopSphere mobile app for authentication via the ShopSphere OIDC Provider, enabling its dual user to log into the ShopSphere system securely and receive the ZK proof for being a ShopSphere account holder.
zkPass empowers associated organizations within the ShopSphere network to perform thorough evaluations of account holder profiles while maintaining the confidentiality of sensitive data.
For a complete integration with the zkPass framework, there are three principal stakeholders engaged in the ShopSphere account holder verification screening process as outlined below:
ShopSphere OIDC Provider (Data Issuer) ShopSphere OIDC Provider assumes the role of the Data Issuer, as specified by the zkPass framework. In this capacity, ShopSphere defines the attributes encapsulated within the ShopSphere ID token as previously described.
Thanks to the format-agnostic nature of zkPass concerning user data, the articulated ShopSphere ID token 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.
Krisna Service (Proof Verifier) Taking the Proof Verifier role within the context of the zkPass framework, the Krisna service backend defines the criteria for the "ShopSphere Account Holder” Data Verification Request (DVR). This DVR encapsulates the eligibility requirements established by Krisna for assessing ShopSphere account holder verification. Krishna user who passes this DVR is deemed as a ShopSphere account holder and, therefore, will be eligible for the 10% discount.
Before generating the DVR, Krisna 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.
ShopSphere App (Data Holder) Developed by ShopSphere, the "ShopSphere" mobile application serves as the main tool for account holders to access a multitude of e-commerce 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. ShopSphere app is designed to securely retrieve customer ID profile data from ShopSphere OIDC Provider databases, implementing stringent authentication protocols to ensure that only authorized account holders gain access to sensitive information. The application collects the “ShopSphere Account Holder” DVR from Krisna and the user’s “ShopSphere ID Token” from ShopSphere, and relays the information to zkPass Service to create the ZK proof for the ShopSphere account holder verification eligibility.
All of the three stakeholders above, ShopSphere OIDC Provider, ShopSphere app, and Krisna service, are essentially the client components of the zkPass framework. Each client uses the zkPassClient library to interact with the ecosystem, as illustrated by the following diagram.
As depicted above, ShopSphere circumvents direct access from external organizations to the ID token, which comprises various personal and sensitive attributes irrelevant to the ShopSphere account holder verification assessment. Instead, Krisna must outline the criteria in the "ShopSphere Account Holder” Data Verification Request (DVR), which the ShopSphere 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 Krisna, thereby preserving the privacy of ShopSphere's customers.
Moreover, an implicit trust relationship exists between Krisna and ShopSphere, as demonstrated. Krisna relies on the assumption that the data encapsulated within the ShopSphere ID Token is both accurate and verifiable.
The "ShopSphere" application acts as the guardian of user-sensitive data and therefore takes the role of the Data Holder. It engages with both the ShopSphere OIDC Provider (Data Issuer) and Krisna service (Proof Verifier) within the scope of the zkPass infrastructure. The primary steps for the ShopSphere app to integrate with the zkPass are explained below.
In this workflow, the user data consists of the OIDC ID token, which Krisna OIDC Provider generates post-successful authentication. This interaction is strictly limited to the ShopSphere user and the ShopSphere OIDC Provider, ensuring the confidential data is only accessible to these specific parties.
The ShopSphere app receives the "ShopSphere Account Holder" Data Verification Request (DVR) token from the Krisna app. Note that the DVR is actually generated by Krisna's service during user authentication. To respond to the DVR query, the ShopSphere app avoids sending any sensitive information directly to Krisna. Instead, it dispatches a Zero-Knowledge Proof (ZKP) produced by the zkPass.generateProof method. This function submits both the user data token and the DVR token to zkPass, which then formulates a Zero-Knowledge Proof on behalf of the user. Once this ZKP is created, it is submitted to the Krisna service for verification. Krisna then evaluates the proof to determine if the user data meets the criteria specified in the DVR.
The entire interactive process is designed with a focus on privacy. No Personally Identifiable Information (PII) is ever shared with the Proof Verifier, emphasizing zkPass's dedication to maintaining user confidentiality while enabling secure data validation.
generate_zkpass_proof
RESTful APIAfter the app has successfully gathered both the user data and the DVR, the next step is to initiate a RESTful API call to the zkPass Service. This call is for the generation of the zkPass proof. To facilitate this, the zkpass-client library includes a handy function named generate_zkpass_proof
, which is designed to make this process more straightforward and efficient.
The app's concluding task involves forwarding the zkPass proof, received from the zkPass service, to the Krisna service for the ultimate verification step. At this stage, the Krisna service can ascertain whether the user in question holds a ShopSphere account. Notably, this entire process is conducted without disclosing any confidential user information to the Krisna service, ensuring data privacy is maintained throughout.
In order to showcase the OIDC (Open ID Connect) Login use case, ShopSphere, and Krisna Bali serve as hypothetical representations for the roles of Data Issuer and Proof Verifier, respectively. It's crucial to state that all underlying components, such as the alliance partnership, ShopSphere and Krisna's authentication systems, and any other related artifacts, are purely hypothetical and fictitious, created solely for the objective of demonstration.
In a strategic effort to accelerate revenue growth, the Krisna Bali store has entered into a strategic alliance with ShopSphere, a foremost player in the national online retail landscape. This collaboration offers a compelling advantage to customers of Krisna who also maintain ShopSphere accounts; they become eligible for up to a 10% discount on select items showcased on Krisna's online platform.
While there are additional facets and details to this partnership, the primary focus of this document is to elaborate on the technical aspects surrounding the login integration between Krisna and ShopSphere. The objective is to enable Krisna's backend server to validate whether a Krisna customer user also maintains an active ShopSphere account.
Merging the distinct user ecosystems of ShopSphere and Krisna presented a complex set of engineering hurdles. ShopSphere utilizes the industry-standard OpenID Connect (OIDC) for authentication, while Krisna employs a proprietary login system with its own dedicated user database. These two systems are inherently divergent and incompatible.
A seemingly straightforward integration strategy would be for Krisna to utilize the OIDC ID tokens from ShopSphere to confirm the identity of a mutual customer, cross-referencing their full name and date of birth. However, this raised justifiable security concerns, particularly from ShopSphere's Vice President of Engineering, about the ramifications of sharing ID tokens containing sensitive customer information with external parties. The concern is further validated by recent security incidents targeting the OAuth protocol, which is integral to OpenID Connect (OIDC), underscoring the importance of implementing robust security measures when sharing ID tokens.
The fundamental requirement for Krisna isn't necessarily accessing the ShopSphere's ID tokens but rather a secure and authenticated assertion that a user, identifiable by their full name and date of birth, is an active ShopSphere account holder. To overcome this challenge, both parties adopted the zkPass Proof-as-a-Service framework. This solution enables the secure, privacy-preserving verification of user credentials, thereby satisfying both parties' technical and security requirements.
To be eligible for the 10% discount on items sold in the Krisna store, a Krisna user account must also have an account with the ShopSphere system. In other words, the “ShopSphere Account Holder” requirement must be defined to determine if the two separate accounts actually belong to the same individual. The user must be able to log in to ShopSphere and Krisna stores, and user attributes of the two user accounts are compared with the following criteria:
The first name and last name must match
The driver's license number must match
The design of the ShopSphere account holder verification aims to achieve the following objectives:
Privacy Protection for ShopSphere Customers In order to safeguard customer data privacy, ShopSphere will not directly transfer any sensitive information to Krisna via its OIDC ID token. Rather, a proof-of-eligibility token, which confirms that the applicant satisfies the predefined “ShopSphere Account Holder” criteria, should be sent to Krisna's backend servers. This approach mitigates the risk of data exposure while maintaining the integrity of the application process.
The objective of this document is to provide a comprehensive blueprint for developing a “ShopSphere Account Holder” verification mechanism that maintains a good balance between operational efficiency, user data privacy, and verifiable query execution. Subsequent sections will delve into the intricate details of the technical architecture, data flow dynamics, and the integration strategies for zkPass.
A straightforward but insecure implementation for the “ShopSphere Account Holder” verification system can be done by sharing the ShopSphere’s ID token with Krisna’s backend system. This is illustrated by the following diagram:
As illustrated in the above diagram, in step 10, Krisna's service receives the ShopSphere ID token. At this point, the Krisna service has some level of access to ShopSphere customer profiles defined in the token. This extraneous information is certainly not needed by Krisna service to determine if the user is a ShopSphere account holder.
Following the zkPass SDK guideline, Krisna defines the “ShopSphere Account Holder” DVR for user Jane Doe. The query of the DVR looks like the following:
The query contains four requirements or conditions for the "ShopSphere Account Holder" verification, which are explained below
iss == "http://oidc-provider.ShopSphere.com" This condition is to ensure that the DVR works on ShopSphere-issued ID token. The "iss" keyword stands for "issuer".
firstName == “Jane” This cross-reference condition is to ensure that the user is Jane Doe.
lastName == “Doe” This cross-reference condition is to ensure that the user is Jane Doe.
driverLicenseNumber == "DL00718256" This cross-reference condition is to ensure that the applicant is Jane Doe by verifying the expected driver's license number. The Krisna previously, through other means, had already acquired and verified Jane Doe’s driver's license number.
Upon receipt of a zkPass proof from the ShopSphere app, Krisna service backend calls the zkpass-client's verify_zkpass_proof function to authenticate the proof. A successful verification indicates that the user indeed has an account with ShopSphere.
When a ShopSphere user has successfully logged into the ShopSphere e-commerce site, the user will receive the ShopSphere ID token from ShopSphere’s backend system. The ID token contains various personal information about the user.
Take, for example, Jane Doe, who is an account holder with ShopSphere, and her ID token is structured in the following manner:
As demonstrated by the above ID token, the user data contains sufficient information needed for determining the “ShopSphere Account Holder” requirement. However, the profile also contains extraneous sensitive attributes that hold no relevance for the “ShopSphere Account Holder” assessment. Transmitting the full profile to Krisna would not only result in superfluous data transfer but also introduce considerable risk to customer privacy. Once stored in Krisna’s server database, such data becomes susceptible to a myriad of security vulnerabilities, ranging from advanced persistent threats (APTs) to unauthorized data access and insider attacks. This escalates the probability of data exfiltration events.
The call sequence for the solution with zkPass integration is illustrated here:
As illustrated in the above diagram, in the zkPass-based implementation, the Krisna service no longer receives the ShopSphere ID Token. Instead, it receives the zkPass proof, which protects the privacy of ShopSphere users.
As depicted in the prior interaction diagram, the ShopSphere app retrieves both the "ShopSphere ID" user data from the ShopSphere OIDC Provider service and the "ShopSphere Account Holder" Data Verification Request (DVR) from the Krisna service. These data sets are then forwarded to the zkPass service for verification processing. Inside the zkPass service, the legitimacy of both data sets is confirmed, and the DVR query is run on the Zero Knowledge Virtual Machine (ZKVM). Subsequently, zkPass constructs a proof outcome, which is then sent back to Krisna service for ultimate validation.
The proof generated by zkPass Service contains a boolean value that signifies whether the Krisna customer meets the conditions set forth in the "ShopSphere Account Holder" DVR. Crucially, this whole process is executed without exposing any sensitive or confidential user data, thus upholding rigorous data privacy standards.