[NCR#1 Proposal] DataMask: a CYC browser extension based on ZK Email programmable provenance

[achab]

Summary

In regulated industries, websites need to restrict access for specific users. For instance, web3 trading platforms might block U.S. residents, betting sites only allow adult, etc. These sites don’t need to know users' identities; they just need to verify that users meet legal requirements. In that case, the usual process of KYC (Know Your Customer) where the user is asked to provide its real data asks too much of the users. Websites just need to check that users are allowed, not to know them. We’ll talk about CYC (Check Your Customer) in the rest of the document for this reason.

Recent cryptography advances, especially zero-knowledge proofs (ZKP), enable providing a technical answer here. The user can create a cryptographic proof showing that he’s allowed to access the content instead of sharing its personal data. The website will then receive the proof, check its validity and - if the proof is valid - let the user access the content. Such a process is relevant as long as the data used to generate the proof comes from a trusted data source - named TDS in the rest of the document. This is where ZK Email can be useful.

ZK Email, which is an audited and production-ready ZKP-based project, crowdfunded by Gitcoin and recently mentioned by Vitalik, is a zk-based project that enables programmable provenance via server-free email verification. It can be seen as a data provenance framework. This trusted data can then be used to generate cryptographic proof that the user is allowed to access the content (country != US, age > 18, etc.). To enable users to generate such proofs and inject them to websites, we propose to build DataMask: a CYC browser extension based on ZK Email programmable provenance. Such browser extension will rely on an extensive list of circuits - written using Noir - and on NoirJS to generate proofs in the browser. We’ll also implement a React component - based on NoirJS as well - to let the website verify those proofs.

Methodology

This project contains two layers of ZKPs:

• ZK Email circuits and proofs: proves provenance of the email,
• CYC circuits and proofs: prove some constraints about the email recipient.

We will build a product that has three parts:

• a backend that can:
  • store ZK Email circuits,
  • store CYC circuits,
  • generate ZK Email proofs.
• a browser extension that can:
  • verify ZK Email proofs to get trusted data,
  • generate CYC proofs,
  • generate ZK Email proofs.
• a React component that can:
  • verify CYC proofs.

Note that ZK Email proofs can be generated either in the backend - in a few seconds - or in the user's browser extension - so emails data stay on the user's side.

We describe the interactions between all parts in the diagram below.

Backend

The role of the backend is to store ZK Email circuits - that represent data we want to extract from emails - and CYC circuits - that represent constraints websites want to check.

We will start by creating a ZK Email circuit that parses a template email that provides the user’s data, and an extensive list of CYC circuits using Noir programs (check age, country, salaries, inclusion in standard data structures, possibly zkML use-cases, etc.) that aims at being a reference for other CYC projects.

When the full project is working for such an email template, we’ll create ZK Email circuits of real TDS: social networks, government identity systems, banks, etc.

The backend should also store CYC circuits for a given website. Sport betting websites and crypto trading websites won’t require the same checks from their users.

Browser extension

The browser extension is used by users: (a) to retrieve their trusted data by verifying ZK Email proofs, (b) retrieve the CYC circuits of the website they want to access and (c) to generate CYC proofs to be sent to the website. In practice, users have to generate ZK Email proofs beforehand, those proofs being stored in their browser storage. We might also consider a separate database in case of technical limitations.

React component

The goal of this component is to enable websites to verify proofs sent by the user via its browser extension. In practice, the component will be built with NoirJS and will be a kind of wallet connect button to let users connect their DataMask extension. When connected, the component will receive CYC circuits and CYC proofs, and will be able to verify CYC proofs.

Once the proofs are verified, the website can safely let the user access the gated content.

Timeline and Deliverables

[6 - 20 Sep] Backend: implement the logic for a template email

Scope:

• Create a ZK Email circuit for a template email.
• Create an extensive list of Noir programs to check user data.
• Create a backend in Typescript to create ZK Email proofs on behalf of users, using NoirJS.

[21 Sep - 4 Oct] Backend: support email templates from TDSs (social networks, banks, etc.)

Scope:

• Create ZK Email circuits for email templates we want to support.
• Refactor backend to support several TDS, and add new ones easily.
• Optimize backend for proving time.

[5 - 18 Oct] Browser extension

Scope:

• Enable generation of ZK Email proofs using SnarkJS.
• Enable verification of ZK Email proofs using SnarkJS.
• Enable generation of CYC proofs using NoirJS.
• Enable extension <> backend interaction with Manifest v3.
• Enable CYC proofs and CYC circuits injection to React component.

[19 Oct - 6 Nov] React component + Testing + Documentation

Scope:

• Create a “DataMask connect” component to let the website verify CYC proofs.
• Increase testing coverage of the project.
• Write a complete documentation for the project.

Team

• Tisura
  • Team working on CYC using Noir and NoirJS
  • Grant recipient of ZK grants round
• Social links:
  • medium
  • github
  • twitter

Team members

Massil

• lead engineer
• github: achab
• telegram: machilassab

Rami

• full-stack developer
• github: 0x18a6
• telegram: x18a6

Abdessamad

• full-stack developer
• github: Brivan-26
• telegram: brivan26

lakonema2000

• backend developer
• github: lakonema2000
• telegram: lakonema2000

Start Date

6 September 2024

[Savio-Sou]

Hi @achab, thanks for submitting the proposal!

A few early questions and thoughts:

Methodology

check age, country, salaries, inclusion in standard data structures, possibly zkML use-cases, etc.

Would be great if you could elaborate, perhaps with example, how CYC could be achieved with zkEmail proofs / how the information is accessible through emails.

Backend

Lovely if additional information on how the backend component is expected to operate could be supplemented. (E.g. is it a part of the browser extension, something that the user runs separately, something that runs on a server, etc.)

Deliverables

Enable generation of ZK Email proofs using SnarkJS.
Enable verification of ZK Email proofs using SnarkJS.

Is the intention here to utilize the Circom implementation of ZK Email?

If yes, best to elaborate how Noir is intended to be leveraged.

[achab]

Hi @Savio-Sou, thanks for questions!

Methodology

Would be great if you could elaborate, perhaps with example, how CYC could be achieved with zkEmail proofs / how the information is accessible through emails.

We'll start with creating a template email that contains all information. Say Michael was born in Singapore on 01/01/2000. He is a US citizen. His bank account balance is $10,000. We'll create a ZK Email circuit for this email, and create the backend based on that.

Then, we'll parse real email from TDS (social network emails, bank emails, gov id emails, etc.), create ZK Email circuits for them and update the backend to support easily several ZK Email circuits & proofs.

Lovely if additional information on how the backend component is expected to operate could be supplemented. (E.g. is it a part of the browser extension, something that the user runs separately, something that runs on a server, etc.)

The backend is expected to run on a server. Regarding ZK Email proving, we use the same approach than zkp2p. We enable both proving on browser side (longer but the user does not reveal email data to the server) and on server side (way shorter).

We could also let the user run the backend. But it would add a non-trivial step to the UX flow, and not all users would have the technical ability to run it.

Deliverables

Is the intention here to utilize the Circom implementation of ZK Email? If yes, best to elaborate how Noir is intended to be leveraged.

Our approach rely on Circom implementation of ZK Email, which is audited and production-ready. We use it as data provenance for our CYC system. We expect several teams to propose to work on a new implementation of ZK Email with Noir, while ours uses what already exists and builds on top of it.

Our project mostly provides two things to Noir ecosystem:

• An extensive list of CYC circuits written in Noir. We want it to be complete and serve as a reference for upcoming CYC projects.
• A browser extension developed in NoirJS. Client-side proving is a game-changer, and a browser extension is the relevant tool to inject signed data (like web3 wallets) or proofs (for upcoming zk-wallets). We also aim our browser extension to serve as a reference, particularly in navigating the recent challenges introduced by Manifest v3.

[Savio-Sou]

Selected proposals for NCR#1 are announced: https://github.com/orgs/noir-lang/discussions/5932

Thank you for your support on the initiative. NCR is just one of the many ways to start your explorations with Noir, check the announcement for more potential ways to collaborate.

Let's bring the world ZK!