-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFP: zkPassport #18
Comments
RFP-0007: zkPassport Implementation Project Intent: Reference RFC: Foundation or Organization Sponsor: Submit by: Application Form Contact Information Team Lead (Main Contact Person): Name: Mahmud Bello Proposed Solution Description: Execution Plan: Initial Setup and Research: NFC Implementation: ZKP Implementation: App Development: Testing and Refinement: Launch and Monitoring: Critical Milestones: Completion of NFC Module: Successfully implement and test the NFC data extraction module. Support Requirements: Grant Funding: Breakdown of funding utilization: Community Engagement: |
Hi, i dropped a proposal for this project a while ago , i would like to know the response on the proposal. |
Hey, We are waiting for another few proposals and will select soon. |
RFP-0007: ## zkPassport with native O1JS on mobile. Overview Passports already containing verifiable credentials for the individual, cryptographically signed by the issuing authorities (countries), allows the possibility for a zk layer to depend upon. We propose building a system such that:
We will provide the necessary tooling to achieve this objective, optimizing for user privacy and ease of use, in the way that is explained below. Our goal is to provide a solid building block to both zkApps and more comprehensive identity protocols, to set arbitrary requirements or make appropriate tradeoffs, based on the passport information for a given user. ePassport PrimerICAO specifies a standard for all ePassports to hold digitally accessible and cryptographically signed information about the owner. We intend to make use of this fact to include passport-backed constrictive identity proof validations in Mina transactions. For our purposes, communicating with a passport over NFC consists of four main steps:
ICAO specification allows the following hashing and signing combinations:
o1js currently supports [RSA, ECDSA, SHA-256, SHA-384, SHA-512], which does not cover SHA-1 and SHA-224. However, according to research of the zkPassport team, SHA-1 usage is not widespread, where SHA-224 is not present. We will support the algorithms o1js implements, which covers the vast majority of current passports and will grow even further for every renewed passport over time. ArchitecturePlan AThere must be a NFC capable device to scan the passport, we plan to support Android and iOS devices via a React Native mobile application, possibly making use of Babel and Metro. This mobile app will handle all communication with the passport, then it will store the credentials it scanned using encrypted storage feature of the OS, requiring only one scan for proofs to be generated. We will probably make use of the well built NFC scanner module from zkPassport team. The app will also produce o1js proofs on demand, for the given constrictions the user is required to fulfill, by running o1js on the mobile device for proof generation. The zkApp will request a proof like "being over 18 years of age and being a citizen of EU" from the mobile app, and will receive a proof to be validated in a recursive manner in a Mina transaction. The communication line must be secure, preferably peer-to-peer. We are thinking of supporting WebRTC or simple file transfer, we believe it is not critical to the proposal at the moment, as an implementation detail. While off-chain storage is not in scope at the moment, we will decide on this during development. We are aware of the problems one might face to run o1js on mobile, we will try Babel and Metro first, avoiding the memory limitation of a WebView implementation. However if that fails, we have a plan B as follows. Plan BIf the mobile device of the user turn out to be unable to generate proofs, we will need to move the computation to user's browser on their PC. We could build a JS library to be used by the zkApp to generate proofs on its own, but we decided against this in order to avoid sharing personal data with a malicious zkApp which may decide to upload that data to somewhere without permission. We could build a website that worked via redirects, just like how Google authentication works, but locally between different tabs. We decided against this, to protect the user from phishing attacks since we would share our codebase for anyone to view or host. Instead, we decided on building an extension similar to familiar web3 wallets. This approach keeps the data on users' own devices, makes use of the computing resources of a comparatively more powerful machine, does not share unnecessary data with parties with unknown intentions, and allows for a really smooth integration with zkApps using a SDK. Only downsides for users are:
Deliverables and TimelineFirst two weeks will be spent on scanning the data from passports via the mobile application. We plan a passport scan bounty program that would find edge cases we as individuals absolutely cannot. This program would start from the moment we feel satisfied with the passport scanning capabilities. As the next step, the mobile application proof generation capabilities will be worked on, we plan to spend two weeks here experimenting. In parallel, the SDK will start to be developed here to generate and validate proofs with simple conditions. At this point, we would welcome any comments or community audits on the soundness of our approach, proof generation and validation in particular. We would love to have some support from the community on this issue, and would welcome any support from o1labs and Mina Foundation. If mobile o1js experiment is successful, we would have a working prototype at six weeks, capable of generating and validating proofs with simple conditions, but without all the bells and whistles. If mobile is unable to support our needs, we will pivot to the extension and the working prototype would be at the end of the ninth week. After the working prototype, we would work on refining the communication between the different devices, between mobile app and either a zkApp or the extension. We would work on improving the SDK between, including supporting more complex proof requirements. We would also hunt bugs and edge cases. We would also write the documentation at this point. We will create a bounty program that rewards users who report errors, which will give us the ability that as individuals we cannot possibly have for edge case detection, since everyone only has limited access to different passports. Also we believe this will result in a healthy community engagement and bootstrap adoption. We plan to finish at 3 and half month in both cases. TeamMain Contact Person: Emre Akbas
Developer: Mehmet Fatih Görgünoğlu
Developer: Egemen Göl
Responsibilities and BudgetMaintaining scope includes:
Developer budget: $7500 per month per developer Total budget = $83000 Recipient Mina address: TBD Possible Next StepsWhile our approach proves that the data is not modified and not expired, it does not discriminate against stolen passports. Our approach could be improved by making live queries against stolen/lost passport databases, using one of the many oracle approaches on Mina. Participating to a service that uses our passport validation approach, requires the user to have a ePassport that o1js supports. We would like to be a building block to one or more, more comprehensive identity approaches, each making its own tradeoffs to support a more universal user base. Also, the credentials storage and proof generation, maybe even the passport scan features could be merged into a Mina compatible wallet, keeping users from installing separate software just for passport credentials. |
Our solution attached here too |
RFC-0001: ZKPassport
Abstract
This proposal introduces ZKPassport, a protocol designed to generate identity-related attestations from a Mina wallet. By enabling users to prove the validity of their identity attributes without disclosing underlying data, ZKPassport enhances the privacy and security of digital interactions. This protocol is applicable across various domains such as finance, healthcare, and online services, providing a robust framework for decentralized identity verification and helping ZKApps defend against sybil attacks.
Introduction
The ZKPassport protocol addresses the challenge of maintaining user privacy while verifying identity attributes. Current digital identity systems often require revealing sensitive information, which can compromise user privacy. ZKPassport leverages zero-knowledge proofs (ZKPs) to allow users to prove the validity of their identity attributes without disclosing the underlying data.
Objectives
Motivation and Rationale
Current digital identity systems face several challenges, including:
ZKPassport addresses these challenges by enabling zero-knowledge proofs for identity verification, ensuring that users can prove their identity attributes without revealing sensitive information. This approach aligns with the goals of enhancing privacy, security, and compliance within the Mina ecosystem.
Scenarios and Use Cases
Age Verification for Online Services
Financial Identity Verification
Open Issues and Discussion Points
Appendices
ICAO Specification
For detailed information on the data accessible via Biometric passports, refer to the ICAO specification.
Public Key Directory
For the public keys required to check the validity of passport data, visit the ICAO Public Key Directory.
References
The text was updated successfully, but these errors were encountered: