Id-mask Proof binding using Passkey/webauthn integration

Mina Navigator Proposals
1

This topic is to discuss the proposal submitted by @iowxss
Please see below for the details of the proposal and discussion.

8th December, 2024
Current status: Under Consideration.
Opened for community discussion on 8th December, 2024.

2

Title

Id-mask - binding proofs to their creators

Project Background

Id-mask is an app that allows the citizens of the Baltic states to create zk-proofs regarding their personal data. It uses Smart-ID to fetch verified personal data into the client-side, o1js to allow users to create proofs related to their identity and mina L1 and google wallet to store as well as consume the proofs.

Id-mask was the first app deployed on the mainnet after the fork. It also served as an example to other teams / developers building solutions reliant on zk-Oracles as well as building zk-programs that rely on data retrieved from zk-Oracle.

Proposal Overview

Problem: Proofs created by one person can be transferred and used by other people.

Despite the app being fully deployed and functional, it has a couple of flaws that block adoption by wider audiences and other businesses. Some of the blockers, like nationality-related limitations of who is able to input their personal data and create the proofs, are going to be lifted in the future once zk-Passport and Private Credentials API is available to use. However, a fraudulent verifying party could collect proofs from users and subsequently reuse or even sell them to malicious third parties. This effectively allows the fraudulent party to hijack the trustworthy user’s identity and exploit it in other contexts or applications. Alternatively, two users could collaborate by using one person’s personal data to generate proofs, which are then transferred to the other person for misuse. In other words, proofs that are created by one person can be given / transferred and used by another person very easily. The proof is a JSON, that can be sent to and used by others.

As long as this issue is not solved, verifying parties cannot be sure that the prover’s proof is safe to trust, governments will not accept and thus businesses will not use these zk-proofs and will not be able to utilize the service that we offer. Also from the investor’s side the interest in this project has been expressed to be limited as long as this issue is not solved. Solving this issue is a crucial step to build trust and boost the adoption of identity-zk-proofs offered by Id-mask.

Solution: We propose to use passkeys and webauthn (try out the demo they provide!), to bind the person that creates the proof to the proof. Passkeys are stored inside the secure enclave of Android / iOS, or other providers such as google credentials manager and can be accessed by either face-ID, fingerprint or in some cases, smartphone’s PIN or pattern. Binding a passkey to a proof essentially allows us to bind it to a face-ID / fingerprint / smartphone together with its PIN or pattern. This will be achieved by binding a public key from passkeys to a proof (the public key of the passkey will be included as one of the outputs of the zkProgram) and then implementing a challenge-response model upon using the proof, where the user is asked to sign an artificial message using its passkeys accessible by face-ID / fingerprint / PIN, pattern. This, as opposed to other solutions, for example face-scan combined with liveness-check, is much more convenient, user friendly, fast and simple approach that requires only a couple of seconds to finish and offers just as good of a solution security and trust-wise.

Previously, similar functionality was only available if the app was developed as an Android /iOS app, but recent developments allow web apps to leverage these features by utilizing webauthn APIs. Use of pass keys was recently enabled by adding o1js support for secp256r1 (also see Gregor’s X post), which is a curve that is used in passkeys. Therefore blockers to implement the proposal have been lifted.

Impact: We are doing a reversed product development. We started by developing the solution for a very generic problem and not a certain use case. Not solving the “transferability” of proofs would severely limit further development possibilities towards more specific solutions. Solving it will lift significant blockers for the app to become usable by parties who are concerned about trusting the proofs. It will also serve as a good example of how to bind proofs to its creators for other developers.

Audience: Our target audience is a triangle of businesses, governments and customers that rely on processes in which Id-Mask has the potential to propose value in preserving user privacy / preventing identity theft and fraud or by simply saving time and effort by making it redundant to store personal data, when actually only the statements about the personal data needs to be known by the verifier. We have worked out a certain use case in which Id-mask could help prevent identity theft / fraud happening on a certain type of platform of which several exist in countries worldwide. Also, other developers that would consider using proofs created using Id-mask, we consider as our audience, who deserve to have a non-transferable solution they can trust.

Architecture & Design

Detailed Design/Architecture:

Diagram on Miro

image
image1498Ă—667 86 KB

After the solution is implemented, when creating the proofs, users will be able to opt in whether to bind the proofs to their mina account, or passkeys, or both. Proof consumers will be able to pose a challenge to the user to prove they own the bind mina account, or passkeys, or both.

Vision for the future:

Technology: Id-mask will become a full zk-powered-identity solution that is universally integrable with other applications, independent of user nationality and specific use case requirements. Technological requirements include binding proofs to people, then allowing everyone to create the proofs via private credentials API and/or zkPassport. After these pieces are implemented, the app will become accessible to users outside of the Baltic States. To meet use case specific requirements, Id-mask will need further components for a successful vertical integration into a web2/ kyc process.

Use cases:

We have narrowed down our target market to one specific type of B2B2C-/C2C-platforms that are very common in Europe and come into use by millions of people every day. Besides the group of victims, we believe, based on reviews and interviews, that there is a bigger group of customers who have not become a victim yet, but who are aware of the risk and are not mitigating it due to the only fact that there is no solution currently available. But trust is a two way street and the “checking” party usually has the upper hand which is shown by the fact that they require the users to expose themselves to access the benefits of the platform, putting their faiths into the platform’s and other users’ hands. It follows that the “checking” party’s needs for a secure identity solution have to be met first. That is why we emphasize the importance of the non-transferability feature. Because to solve the fundamental problem of building trust between two parties on a platform, the risk of a transferable proof must be mitigated before talking about further implementations to protect user privacy.

Potential investors have expressed interest in Id-Mask in making it a B2B-SaaS product. However, the transferability came up usually in the first interview / introduction. Also, adding more software components to develop Id-Mask towards a vertical integration into existing processes was mentioned as a requirement for potential external investments.

Existing work:

  • Id-mask on Github.
  • Exploration of webauthn API to sign artificial messages.
  • After the core logic of the app was fully developed, we have implemented a feature to mock-solve the proof-transferability problem by embedding a mina public key into the proof, allowing the consumer to challenge the user to prove that they own that public key (in a non-zk way). This in a sense is supposed to solve this problem, but private keys to a Mina account can still be transferred from one person to another. Therefore, even though this solution demonstrated the logic of the challenge-response system to prove ownership, it was not completely bulletproof. Nonetheless, it serves as a proof of concept of how a passkeys-based system would work. Here is a video demonstration of this functionality.

Production Timeline: The proposed new features of the app will be deployed to prod by the end of the 3 months deadline.

Budget & milestones

Deliverables:

  1. Smart contracts updated with the logic of consuming signed payload (secp256r1) and passkey’s public-key and verifying the signature inside the circuit;
  2. Id-mask UI that allow users to create proofs and bind them using passkeys;
  3. Id-mask Backend implementing the logic of mediator and storage to facilitate challenge-response model between proof owner and consumer.
  4. Id-mask UI that implements the challenge-response model to ask user to use passkeys to sign an artificial message open proof consumption by a third party;

Mid-Point milestones: 1 and 2.

Project Timeline: 3 months

Budget Requested: 36k MINA

Budget Breakdown:

  • Deliverable 1: 3 weeks, 9k MINA
  • Deliverable 2: 4 weeks, 12K MINA
  • Deliverable 3: 1 weeks, 3K MINA
  • Deliverable 4: 4 weeks, 12k MINA

In other words - 12k MINA (single software developer salary pre-taxes) * 3 months.

Wallet Address: B62qnuJGE11DiYL1WJm1UQafjMvqinEZfXK2i2K9TNwMY27iKTxmGWd

Team Info

This section provides details about the team.

Proposer Github: https://github.com/raidastauras.

Proposer Experience (Mina and o1js):

Team Members:

Achievements:

  • Id-mask was the first zkApp to be deployed on mainnet.
  • Id-mask is one of the first end-to-end working apps aiming to serve customers through a real world use case.
  • Id-mask has attracted attention from potential investors due to its straightforward presence online and novelty compared to current identity solutions.

Risks & Mitigations

Some of the operations required to verify a passkeys signature might be chalanging to implement using o1js (see “Construct the data that `navigator.credentials.get` used to sign” https://gogo-webauthn.fly.dev/blog). If this becomes a problem, some of the data preprocessing required to verify a signature as part of the circuit can be moved out of the circuit to plain typescript. This would mean instead of passing over multiple data items and hashing and merging them inside the circuit, all of this can be implemented out of the circuit without sabotaging the app logic and trust.

A Known Edge Case: When two individuals collaborate during the proof creation process to intentionally cheat the system. For example, Person A may provide their passport and personal details to Person B, who then uses this private information to create an identity proof and link it to their passkeys. This allows Person B to create and use a proof that is based on Person A identity data. Using of passkeys and webauthn does not prevent such scenario from happening. However, this proposal reduces this risk by requiring people to be physically together when creating the proofs.

1 Like
3

Really good proposal and solution to the potential misuse of digital ids.

I think digital id is a huge use case for an zk and Mina and this team have proven their credentials (sorry bad joke) to deliver on their ideas. Good luck!

2 Likes