# General Grant Proposal (DRAFT)

* **Project:** Proof of Baguette

## Project Overview :page_facing_up:

### Overview

Proving uniqueness of individual is key to build sybil-resistant applications. Fortunately, UN countries in association with the International Civil Aviation Organization have built a great tool for us to piggyback on: electronic passports.

By extracting RSA signature from e-passport chips using NFC and verifying them on-chain in a zk circuit, it's possible to guarantee uniqueness of identities while allowing for privacy. Additionally, it's possible for the user to selectively disclose personal data (like their nationality or their date of birth).

This grant proposal aims at funding the development of this new privacy-preserving tool, with applications in sybil resistance, wallet recovery and group membership disclosure.

### Project Details

At ETHGlobal Paris, we prototyped:
* A demo android app extracting the signatures from passports.
* A circom circuit verifying the RSA signature, inspired by already existing zkRSA implementation.

Our aim is to make this new primitive an open source public good that can be used by any project in the ecosystem for sybil resistance and selective disclosure. It could be integrated into tools like Semaphore, Unirep, Bandada or PCDPass.

To do that, we would need to build :
* An optimized circuit that can verify RSA signatures of country authorities and selectively disclose private info from electronic passports.
* A cross-platform (iOS + Android) app able to extract signatures from e-passport chips and that allows the user to generate a zkproof on his phone, without ever sending his private data to a server.

Similar ideas have been proposed in [zkcred](https://eprint.iacr.org/2022/878.pdf) and [cinderella](https://antoine.delignat-lavaud.fr/doc/oakland16.pdf). However, we don't know of any efficient and accessible implementations for passports.

#### Circuit

The structure of the circuit is as follows :


All the data needed to derive the message that ends up being signed by the country authority is extractable using NFC.

The primary focus of this project is to verify the following data:
- First name
- Last name
- Nationality
- Date of birth
- Gender
- Expiration date of passport
- Passport number

While out of the scope of this project, the following types of data can also be verified when available:
- photo
- optional in passports:
- Place of birth
- Address
- Telephone number
- Profession
- Persons to notify

Biometric data like fingerprint and iris can't be accessed, as they require special authorization.

For the circuit, the main challenge to be overcome is performance. As explained later, the proof has to be made in a smartphone, because it's the only widely available NFC reader. Smartphones have very limited RAM. Also, it would be good for proof generation to be fast.

Based on prior benchmarks, we chose Halo2, specifically the Axiom version using KZG polynomial commitments.

#### Mobile app

The only way to extract data from e-passport chips is through NFC. Few have an NFC reader at home. Fortunately, we all have one in our pocket. Thus, whatever the usage, the most coherent is to do a mobile app.

To do it, we plan to use react-native so that the app works both in iOS and Android environments. Unfortunately, there is currently no js implementation of the protocol used to interact with passports. Thus, we have to use native modules:
- a native module using code from [tananaev/passport-reader](https://github.com/tananaev/passport-reader) for android
- a native module using code from [AndyQ/NFCPassportReader](https://github.com/AndyQ/NFCPassportReader/) for iOS

The fastest way to generate proofs is through [rapidsnark](https://github.com/iden3/rapidsnark) for groth16 and [halo2_proofs](https://github.com/zcash/halo2/tree/main/halo2_proofs) for halo2/plonk.
Interacting with the proving schemes will thus happen through a wrapper native module

To be able to read the private information, the passport specification implements a security feature: Basic Access Control. Users have to type their passport number, date of birth and the date of expiry of the passport. We plan to have the users type them. It's possible to use computer vision to read the data but it's out of the scope of this project.


#### SBT

Our first application of this new tool is the Proof of Passport SBT.

To avoid replay attacks, we use the keccak256 hash of the rsa signature as a nullifier. If someone attempts to use the same proof twice to mint a second SBT, the transaction will not go through.

To avoid having the transaction seen in the mempool and being frontrun by an attacker, the minter commits to their address in the proof. The SBT can only be minted to the address committed in the proof.

#### Other challenges

- Adapting to the e-passport specifications: for now, all the passports we have tested work with our MVP, but the e-passport specifications have some edge cases that we will need to manage to ensure that our tool works with all passports.
- Managing the public keys registry: the ICAO, along with countries like Germany and France frequently publish masterlists containing the RSA public keys of all e-passport emiting countries. For on-chain verification, it's necessary to manage this list on-chain, just like zk-email does. For off-chain verification, we can make the list accessible through an API endpoint.

## Team :busts_in_silhouette:

### Team members
* Florent
[e-mail]
Tg: @FlorentTavernier

* Youssef
[e-mail]
Tg: @yssf_e

### Team's experience
Our team has experience in cross-platform app development. We built Bangr, an account abstraction based wallet app.
We also have experience in smart contract development, including in DeFi protocols.
More recently, we've produced the mvp of this project and experimented writing circuits in circom, halo2 and noir.

### Team Code Repos
* https://github.com/yssf-io/passport-sbt

## Development Roadmap :nut_and_bolt:

### Overview

### Milestone 1: Main Circuit

| Number | Deliverable | Specification |
| ------------- | ------------- | ------------- |
| 0b. | Documentation | We will provide inline documentation of the circuit code and detailed explanations on the github readme |
| 0c. | Testing Guide | The circuit will have proper test coverage. In the guide we will describe how to run these tests |
| 1. | Functionality: Verification of RSA | Our circuit will use the current best implementation of zkRSA in halo2 |
| 2. | Functionality: Verification of SHA256 | Our circuit will use the current best implementation of dynamic-length SHA256 in halo2 |
| 3. | Functionality: Address commitment | To avoid the transaction being frontrun, the user commits to the address that sends the transaction in the circuit, so that the proof cannot be used by anyone else. |
| 4. | Application: Main Passport signature verification circuit | We will write a zk circuit that verifies the RSA signatures included in electronic passports. The signatures match the pkcs#1 v1.5 specifications |

### Milestone 2: Circuit - Selective Disclosure

| Number | Deliverable | Specification |
| ------------- | ------------- | ------------- |
| 0b. | Documentation | We will provide inline documentation of the code and detailed explanations on the github readme |
| 0c. | Testing Guide | The circuit will have proper test coverage. In the guide we will describe how to run these tests |
| 1. | Functionality: Private info --> signed hash | From the private information of the user (MRZ) and intermediate hashes extracted by the app, our circuit will be able to reconstitute the message signed by the country authority |
| 2. | Functionality: Selective disclosure | The circuit will allow proofs to selectively disclose private data. It includes nationality, date of birth, etc. The full list is detailed above |
| 3. | Application: Verification circuit with selective disclosure | The inputs of the verification circuit will include the user's personal info, in a way that makes them selectively disclosable |

### Milestone 3: Cross-platform app

| Number | Deliverable | Specification |
| ------------- | ------------- | ------------- |
| 0b. | Documentation | We will provide inline documentation of the code and explanations on how to build the app the github readme. |
| 0c. | Testing Guide | The app will have tests. In the guide we will describe how to run these tests |
| 1. | Functionality: React Native app | The core of the app is in react native. It prompts users for their name, their date of birth and the date of expiry of their document. Then, they are asked to put their smartphone on their passport to scan the NFC chip. Then, they can either use the proof in identity systems with integrations, or they can be prompted for an address or an ENS to mint the SBT on a low-fee chain like Gnosis or Polygon |
| 2. | Functionality: iOS Module | The iOS native module will communicate with the passport to extract the passport information and signature. It's written in Swift |
| 3. | Functionality: Kotlin Module | The Android native module will communicate with the passport to extract the passport information and signature. It's written in Kotlin |
| 4. | Application: Cross-platform mobile app | We will develop a mobile app that allows users to mint an SBT. The SBT will include the private data they wish to reveal |

### Milestone 4: Public Key registry

| Number | Deliverable | Specification |
| ------------- | ------------- | ------------- |
| 0b. | Documentation | We will provide inline documentation of the code and explanations on how to compile and deploy the contracts in the github readme |
| 0c. | Testing Guide | The contracts will have thorough tests |
| 1. | Functionality: Onchain pubkey registry | We will extract the current public keys of country authorities and write a contract that stores them. This allows for our SBT or any other contract to verify the RSA key against one stored in the contract |
| 2. | Functionality: Offchain pubkey registry | For any application that needs to verify to proofs offchain, we will also provide an api endpoint that returns the last masterlist parsed, with the RSA public keys of governments |
| 3. | Application: Pubkey registry | The registry contract can be deployed on any EVM-compatible blockchain. Any application will be able to use this registry to verify government rsa signatures. There is a question as to who controls the onchain public key registry. The question is similar to the case of [zk-email](https://github.com/zkemail). The most future-proof approach is through a multisig. In any case, as it's all open source, any app could deploy its own registry for its own set of smart contracts. |

### Milestone 5: SBT

| Number | Deliverable | Specification |
| ------------- | ------------- | ------------- |
| 0b. | Documentation | We will provide inline documentation of the code and explanations on how to compile and deploy the contracts in the github readme |
| 0c. | Testing Guide | The contracts will have thorough tests |
| 1. | Functionality: SBT | We will write a SBT smart contract that allows users to mint an SBT with the information they want to selectively disclose. |
| 2. | Functionality: Nullifier | The contract will store the nullifier so that no user can mint multiple SBTs. |
| 3. | Functionality: Expiration | The SBT will have a validity date that coincides with the expiry date of the passport |
| 4. | Application: SBT with nullifier and expiration | We will write a SBT smart contract that allows users to mint an SBT with the information they want to selectively disclose. The contracts can be deployed on any EVM-compatible blockchain. They will allow composability with applications in the Ethereum ecosystem |

## Additional Information :heavy_plus_sign:

In the case where an unexpected problem prevents us from making proof generation work on the phone with the halo2 circuit, we will do the circuit in circom, using [circomjs](https://github.com/getZeFi/circomjs) for witness generation and [rapidsnark](https://github.com/iden3/rapidsnark) for proving.

Using passport still has limitations, like loss and revocation. We can account for passport expiration by exposing it in the circuit and recording it in an SBT or a database, but if the user looses their passport and gets a new one from the government, they could still mint a new NFT. Same thing for governments revoking passports. There is also the question of individuals who hold multiple citizenships. We are currently working on a nullifying scheme that could guarantee uniqueness in this case. We believe those edge cases will need to be addressed as usage of this kind of tools goes up.

We believe there is great potential in integrating this project with other PSE projects like Semaphore, Unirep, Bandada, PCDPass or the Country Identity Kit from anon-aadhaar. However, due to the complexity of the circuit and the app, these integrations are out of the scope of this project. They can be the subject of future work.