# Account abstraction multifactor authorization using WebAuthn

## **Project Abstract**

Given all the possibilities created by the account abstraction implementation, authorization from a user perspective will be always a challenge. We intend to solve that by providing a generic way for users to be protecting their wallets with an extra layer of security when authorizing transactions - which can be their fingerprint, face, a usb device etc. A lot of existing technologies, that can be found in both desktop and mobile, like TouchID, FaceID etc., currently make this possible via the WebAuthn standard, and we plan to research and build a generic and easy to use way for integrating this in a smart contract wallet and in any Web 3 application.

## **Objectives**

Our main objective is to provide a great UX for developers to easily integrate this feature in their applications, without much hassle, and the same great UX experience for the end users that will be using this.

We intend to achieve that by setting a goal to define generic primitives that any Web 3 project can use to integrate WebAuthn for their use case that uses smart contract wallets.

These generic primitives will enable integration with the smart contract wallet account (via extensibility or pluggable component), as well as an integration in the application’s backend, in a seamless way. Any new or existing Web3 project that wishes to either include an extra layer of security for their user’s access to their wallets, should find it really easy to do.

## **Outcomes**

The Ethereum Ecosystem benefits a lot by onboarding new users into the Web3 space. Account abstraction is supposed to make it super simple to onboard the next billion users into the space, however, it needs a lot more work to make it simple for developers of the applications to have a seamless UX for developing apps that utilize this concept to its full potential, and it needs to make it easy for any type of user to easily interact with it.

We intend to solve one piece of the puzzle and propel this forward by focusing on two things - great developer UX for building smart contract wallets that utilize WebAuthn standard and a seamless approach for integrating this in their applications.

## **Grant Scope**

In this section we outline a detailed scope we aim to cover as part of this grant.

- Research the scope for storing the device’s public key on chain, as part of the user’s account. We intend to focus on several areas to figure out the best UX from a developer point of view and answer several questions as part of this effort:
- Security aspects related to adding and removing devices, like preventing replay attacks for both registration of a device and signing transactions. Proper definition of the payload that needs to be signed by the user’s device.
- Support for aggregated and non-aggregated signatures. What is the best experience for using aggregated and non aggregated signatures that include WebAuthn signatures?
- How can existing contracts that implement ERC4337 integrate this feature without much complexities? We intend to build this as an extensible component for new & existing smart contract, however we need to research the design tradeoffs we need to make in respect to security and other concerns.
- Can we somehow utilize zero knowledge proofs to mitigate potential security risks and perform proof validation on-chain? ZK might be an overkill for this use case, but we intend to spend non significant time figuring out pros & cons.
- Research the scope & feasibility for verifying WebAuthn signatures on chain:
- Given the supported signing algorithms in the [WebAuthn specification](https://w3c.github.io/webauthn/#typedefdef-cosealgorithmidentifier), which include ed25519, we intend to research if and what other algorithms can be supported by the devices that implement this standard (whether ECDSA can be utilized), how extensible is that approach, and how expensive is [ed25519 verification on chain](https://ethresear.ch/t/verify-ed25519-signatures-cheaply-on-eth-using-zk-snarks/13139).
- Research the best way to integrate the smart contract and the server application, by focusing on several areas:
- Given that Webauthn needs a server-generated challenge, we intend to explore whether something like that could be feasible to be done on-chain, with ZK proofs.
- We also want to answer the question of integrating both the server and the smart contract operations for challenge generation, metadata storage, verifying the generated key and origin (we intend to explore potentially using lightweight zk proofs to minimize trust assumptions with the server interactions)
- Development of an extensible Smart Contract using the Foundry smart contract development toolchain that can be used by any smart contract wallet that either implements `IAccount` or `IAggregatedAccount` that provides the option to add and remove device public keys, as well as verify signatures. This can be used in several ways, and we intend to provide extensive documentation and tutorials on how to use it:
- Multisig authorization for transactions/user-operations.
- Password-less access to the application and certain interactions with the smart contract, which might not necessarily be related to transactions, as well as signing server messages which can be authenticated on-chain for specific purposes.
- Backend and Frontend SDKs that can be built in Go and TS respectively given the language popularity in Web3 space. These SDKs will be mainly used to abstract the registration and removal of keys, perform proxying to the smart contracts from the backend (depending on thee app needs, if any), and abstract away the WebAuthn browser APIs, relieving the developer from having to know anything related to WebAuthn.
- A full open source example application that utilizes these features. Web3 projects can be expected to use this as a starting point for their projects, or use it to upgrade their existing apps. This example can be a simple wallet.

## **Project Team**

The team consists of 2 people, Nasi & Blagoj. We have previously worked with Ethereum foundation as part of the Privacy and Scaling Explorations Group.

We intend to allocate 15-20 hours each per week on this project.

## **Background**

**Blagoj**

Discord handle: **tcb#8990**

Previously a Project Lead for the RLN project at Ethereum PSE. Worked extensively with Semaphore and contributed towards its development. Extensive experience in the crypto space, largely with smart contract development and auditing, as well as security and cryptography.

**Nasi**

Discord handle: **nasi#0962**

Previously a member at Ethereum PSE. Worked with applying zero knowledge primitives towards building production-ready applications. Built ZK-chat, a production-ready, anonymous and spam resistant chat application, which utilizes RLN underneath. Extensive experience in distributed systems, DevOps and software architecture design.

We both have over 5 years of experience in software development, and currently we are both building Diagonal, the API for crypto payments, and we are actively researching into building great user experiences for users that need to interact with smart contract wallets.

Github Profiles

1. Blagoj - [https://github.com/b-d1](https://github.com/b-d1)
2. Nasi - [https://github.com/njofce](https://github.com/njofce)

**References & Previous Work:**

1. ZK Chat - open source [https://github.com/njofce/zk-chat](https://github.com/njofce/zk-chat%5D(https://github.com/njofce/zk-chat))
2. RLN post - [https://medium.com/privacy-scaling-explorations/rate-limiting-nullifier-a-spam-protection-mechanism-for-anonymous-environments-bbe4006a57d](https://medium.com/privacy-scaling-explorations/rate-limiting-nullifier-a-spam-protection-mechanism-for-anonymous-environments-bbe4006a57d)
3. Rollup Diff - [https://medium.com/privacy-scaling-explorations/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-d14291acc825](https://medium.com/privacy-scaling-explorations/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-d14291acc825)

## **Methodology**

We intend to start from the user experience - first from the developer experience and then from the end user experience, and build a demo application that will support multi factor authentication when sending a transaction via a smart contract wallet that implements ERC-4337. As part of this effort we intend to perform the research steps defined in the Grant Scope, answer the defined questions and future questions that will arise, refine and adjust the scope, and define the proper requirements in terms of the application behaviour.

We expect to spend most of our efforts on researching and answering the questions outlined in the Grant Scope. Based on the requirements outcome we will evaluate whether utilizing ZK proofs in any part of the design would be a viable approach for this solution and whether it can be useful at all, and if yes, we will design the circuits, along with the smart contracts.

We are certain that implementing the abstracting SDK and the smart contract/s would be relatively simple after the overall solution is designed, so that would be the last step, along with refining the demo application into ready to use code, that can be utilized by anyone.

To summarize, our high level deliverable goals are the following:

1. Provide extendable smart contracts that can be used by wallets that implement ERC4337 to support additional functionality to manage WebAuthn devices, and validate transaction signatures as part of the user operation flow, marking it as a multisignature transaction.
2. Provide SDKs that can be used in web and server side, which abstract away the whole WebAuthn configuration and verification, as well as the interaction with smart contracts.
3. Provide examples and tutorials on how new and existing applications that utilize ERCC4337 standard can easily use it. Our end goal is to allow the developers to integrate this extra authentication step in very short time (days not weeks) and make it available to end users.

## **Timeline**

We can split this project in several milestones, and in this section we propose some rough estimations.

### M1. Research Phase

As described in the Grant Scope, we intend to perform an extensive research starting from the User Experience, and answering the existing questions and other questions that will arise:

- How can we connect a certain FIDO device with a smart contract wallet? We already know that we need to store the verification key on chain. Our plan is to research how to store data and in which format, taking in consideration any security concerns.
- Which signature schemes and algorithms we will utilise for FIDO device signature verification? We need to research and decide which signature scheme to use, based on FIDO device support as well as the on-chain implementation/usage feasibility.
- How are we going to handle device management onchain? We plan on designing an architecture which will take into account registering and removing devices while enabling good UX.
- What are the security risks in terms of privacy for device management, and can we use ZK-Proofs to mitigate those? Can we use ZK-Proofs to achieve privacy preserving device management?

**Estimated Timeline:** 6 weeks

**Deliverable:**

Research document regarding the findings, based on the initial research questions. Formal specification about the implementation, including architecture diagrams and design decisions will be included as well.

The artifacts from this phase would define the technical components that needs to be developed on different levels of the stack as well as define the whole user flow.

**Fund Allocation:** The funds will be allocated mainly for the researchers at this stage.

### M2. Implementation Phase 1

After we have selected the exact approach we want to move forward, we are ready to move to the implementation phase. Depending on the approach with are moving forward, we have split the implementation phase into 2 parts, as it would include several components. In this phase, we will focus on:

- Extensible smart contract development as a core part of the solution. This includes defining operation types and developing a FIDO device signature on-chain verification solution.
- Development of external interfaces, integration and e2e tests which also showcase the whole user flow interacting with the smart contracts
- Development of deployment scripts and specifying a deployment process
- Internal smart contract auditing and optimisations for efficiency and gas costs
- Example on how to integrate with the existing EIP 4337 architecture (factory and wallet contracts)
- Design for a full stack demo application which will utilise the smart contracts and WebAuthn standard
- ZK circuit design for onchain device management and server challenge generation/verification (this is to be determined if it is necessary in the research phase)

**Estimated Timeline:** 8 weeks

**Deliverable:** A generic smart contract design, including tests, and the actual implementation for the circuits if needed. Also, delivering the design for the second stage.

**Fund Allocation:** The funds will be allocated for the researchers and for any cloud deployment costs.

### M3. Implementation Phase 2

In this phase, we will focus on developer tooling and building the example application that will utilise WebAuthn authentication using the previously implemented architecture:

- The SDK that will be used by the applications to perform the necessary interactions for generating the server challenge and any other server signatures or proofs, as well as to abstract the WebAuthn API, specifically to smart contract requirements.
- The example app with the exact interactions with the smart contracts and the server. For the example application, we’re planning to develop a web application which has login and sign up features and uses two factor authentication. We plan to build a simple dashboard which allows for viewing the user’s data (created wallet) and allows for device management.

**Estimated Timeline:** 6 weeks

**Deliverable:** The actual implementation of the abstraction SDK and the continuation of the example app that will be using the smart contracts and the SDK on the server side to perform the entire flow.

**Fund Allocation:** The funds will be allocated for the researchers and for any cloud deployment costs.

### M4. Documentation

In this phase we plan to document the whole implementation, as well as to create presentation materials for the example application.

This involves the whole smart contract architecture, any backend and frontend code as well as the deployment process.

We also plan to include further steps and write about potential applications that can be built on top of our system.

When the whole implementation is done, we intend to have a ready-to-use code of the example application, as well as full documentation of the open source code.

**Estimated Timeline:** 2 weeks

**Deliverable:** Full documentation and open source code

**Fund Allocation:** The funds will be allocated for the researchers.

## **Budget**

We do expect to deploy some applications in the cloud to test things out, and we don’t require any specialized hardware to do so. The costs for the cloud should be minimal, and we can roughly estimate those to **~200$** for the overall research period.

The rest of the budget is intended for the researchers. The following calculation includes the cost for both researchers for part time work during the defined period, based on the given estimates.

Estimated weeks of work: **22**

Estimated Budget: **50.000$**

Estimated budget breakdown by milestones:

M1: 13.000 $

M2: 18.000 $

M3: 13.000 $

M4: 6.000 $