Please describe your proposed solution.

A browser wallet is crucial for gaining massive adoption of Atala PRISM. We saw this when MetaMask was released. Since then, it unlocked the Ethereum ecosystem to any developer. I expect that this PRISM browser wallet does the same for Atala PRISM.

Key details:

• A browser extension is a natural component for identity projects that intend to gain massive adoption. It will allow individuals to manage and control their identities and data.
• Exposing an API through a browser extension allows developers to access the PRISM ecosystem in a couple of hours.
• There will be a Browser Extension that people can install from the applicable web stores (Chrome/Firefox).
• The project should be completely open source.
• Real use-case scenarios could leverage this wallet, like allowing people to log into a web app with Atala PRISM.

What users get

Once a user installs the extension, it will allow the user to:

1. Create or recover an identity wallet based on Atala PRISM.
2. Create as many identities as needed, based on Atala PRISM Decentralized Identifiers (DIDs)
3. Interact with different Atala PRISM networks (testnet/mainnet/local).
4. Self-issue a verifiable credential.
5. Receive verifiable credentials issued to you.
6. Interact with web applications that support Atala PRISM.
7. Choose which web applications can interact with the wallet.
8. Choose what to share with specific web application.
9. Use a different identity for interacting with every web application.

What developers get

For developers, it will enable them to build web applications that interact with the user's wallet by a clearly defined and simple-to-use API, including ways to:

1. Request the user to authorize interactions with the wallet.
2. Request the user to prove that it owns an identity.
3. Request credentials from the user's wallet.
4. Submit credentials to the user's wallet.

Please describe how your proposed solution will address the Challenge that you have submitted it in.

A browser wallet unlocks the Atala PRISM ecosystem to web developers. The API will allow developers to interact with Atala PRISM immediately, growing their confidence in integrating Atala PRISM with their web application.

This extension is critical for any identity solution because it allows any web application to reap the benefits of Atala PRISM.

What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?

The main risk is that the Atala PRISM project doesn't become public soon, which would prevent people from using their wallets for real scenarios.

There are no risks to the technical capabilities because we have already solved the key technical challenges from this project.

Other potential risks are:

1. The leading developers involved in the project can't continue the work. In such a case, I have many developers with similar skills in my company (https://wiringbits.net), which I'd leverage to avoid the app development getting stuck. The worst-case scenario would be that I can't get more internal devs, and I'd need to hire external people, which can introduce delays.
2. Delays due to external factors. For example, we could run into issues with the Atala PRISM SDK. With my extensive experience with Atala PRISM, I'm confident I could create a workaround.
3. Delays due to wrong estimations in the project, given that I have a Software Development company (https://wiringbits.net), I can leverage it to fund any extra work we did not anticipate.
4. I could get into an accident or something that prevents me from working on the project. It is an extreme scenario, but I believe that having everything open sourced will allow my team or the community to continue the development.
5. The web stores can delay us from publishing the extensions. In such a case, we'd provide binary files for people to play with app, as well as instructions to build and install the extension from the source code.

Please provide a detailed plan, including timeline and key milestones for delivering your proposal.

The application will be built in several iterations, each iteration involves writing automated tests to prevent future changes from breaking old functionality.

Week 1 to 2 - Preparation steps

Let's do the necessary bootstrapping work to get started on the project, tasks include:

• Project creation.
• Set up the continuous integration (CI) workflows.
• Capture the relevant tasks in a Kanban board.
• Make sure we have the necessary access to play with the Atala PRISM ecosystem (SDK + PRISM Node).
• Write the necessary boilerplate code, creating a sample extension that can be bundled for the Chrome Web Store.
• Choose a theme for the application.
• Create the base to create tests for the application.
• Design the application flows to be implemented.

Week 3 - PRISM SDK Wrapper

It is ideal to write a small wrapper in order to use the Atala PRISM SDK smoothly, this way, there will be a single layer that interacts with PRISM which allow us to decouple the code from the SDK.

The overall goal is to have the following methods available:

• Generate a mnemonic seed.
• Generate a DID from a mnemonic seed.
• Publish DID.
• Resolve DID.
• Update DID.
• Issue credential.
• Publish credential.
• Resolve credential.
• Revoke credential.
• Verify credential.

Week 4 to 6 - Wallet API

We'll need a low-level API that allows the view layer to do the necessary wallet operations, which includes the following:

• Storage layer (Accounts/DIDs, credentials, operation history, settings, connected websites).
• Create/Recover wallet.
• Account management (create/publish/export/import).
• Credential operations (issue/publish/verify/export/import).
• Update settings.
• Manage website connections (allow/disallow).
• Lock/Unlock wallet.

Week 7 to 8 - Main pages

By now, we should have everything necessary to complete the user interface (UI), let's start with the main pages:

• Welcome/Farewell.
• Create/Recover account.
• Main dashboard.
• Settings
• Operation history.
• Network selector.
• Locked wallet.
• Unlock wallet.
• List website requests.

Week 9 - Credential pages

There are pages that require functionality specific to credentials:

• Display the available credentials.
• Create a credential.
• Display a credential.
• Import a credential.
• Export a credential.
• Publish a credential.
• Revoke a credential.

Week 10 - DID pages

There are pages for DIDs:

• Display a DID.
• Publish a DID.
• Export a DID.
• Import a DID.

Week 11 - Web App bridge pages

We need pages to handle the website interactions:

• Allow/Disallow website.
• Review website request.
• Select credential to be shared to a website.
• Receive credential from a website.

Week 12 - Final pages

At last, we'll include extra pages that are useful for the app:

• Network manager.
• Network selector.
• About.

Week 13 to 14 - Internal QA + bugfixes

Let's take some focus on testing the application to address potential corner cases that haven't been handled before.

This period should help us to cover anything that we could have missed before.

Week 15 to 16 - Cross-browser compatibility fixes + publish to the web stores

There is some work required in order to support more than one browser with the same source code, let's do the necessary adjustments so that our application works in the main browsers (Firefox/Chrome/Safari).

This period should also cover the necessary work that is required to publish to the web stores.

Week 17 to 18 - Internal security audit + fixes + security docs

This application intends to be crucial for the PRISM ecosystem, given that it will deal with sensitive data, it is natural to put some effort on finding ways where the security could be compromised, as well as put effort on fixing those.

We should report our findings as well as the known issues that we plan to fix in another iteration.

Week 19 to 21 - End to end automated acceptance tests

In order to avoid breaking the application when submitting fixes/updates, it is ideal to have an end-to-end automated test suite for the acceptance use cases.

Browser extensions like this one are known to require a complicated set up to run these scenarios, let's find a practical way to write these end to end tests and prepare tests for the main use cases.

Week 22 - General project documentation

Let's write the necessary documentation for:

• Getting developers started with integrating a web application.
• Getting developers started to contribute to our application, setting up the development environment, running tests, etc.
• Publishing the application to the web stores.

Week 23 - Example web application

Let's create an example web application that interacts with PRISM.

Please provide a detailed budget breakdown.

The budget is estimated based on the following team.

Senior Software Engineer

Responsibilities:

• Implement the application flows.
• Coordinate with the Technical Architect to ensure the project has good quality.
• Coordinate with the Technical Architect to solve the technical challenges.
• Design a simple to use User Interface.

Rate: $2500 USD/week by working full time (40h/week).

Technical Architect/Lead

Responsibilities:

• Manage the team.
• Plan the project execution.
• Communicate the progress to the community.
• Prepare demos.
• Design the complex parts of the application.
• Review the code written by the team.
• Design the application flows.

Rate: $1000 USD/week by working 10h/week.

Please provide details of the people who will work on the project.

Alexis Hernandez

Alexis used to work for IOHK on the Atala PRISM team. He was involved in Atala PRISM from the beginning by designing most of the components. He was the Atala PRISM Technical Architect, leading the development for over two years.

Alexis participated heavily in the design and development of the internal Atala PRISM Browser Wallet, which is similar to this proposal. The main difference is that the proposal targets individuals while the internal wallet targets institutions. There is a demo showcasing such a wallet (https://www.youtube.com/watch?v=wemcgPA3IPQ).

Alexis was also involved in many other Browser Extension projects, even creating its reusable template that has helped many people to build browser extensions (https://github.com/AlexITC/chrome-scalajs-template). He also maintains the SBT plugin for writing Browser Extensions in Scala.js (https://github.com/AlexITC/scala-js-chrome).

In addition, Alexis runs a successful development company (Wiringbits) whose primary focus is on web and blockchain development (https://wiringbits.net).

Links:

• https://github.com/AlexITC
• https://www.linkedin.com/in/alexis-hernandez
• https://wiringbits.net
• https://github.com/wiringbits

Cesar Gurrion

Cesar is an experienced frontend developer who loves the blockchain space, He is also part of Wiringbits, where he has been able to contribute to several cryptocurrency projects.

Cesar also worked as a contractor for IOHK, where he made considerable improvements to the internal Atala PRISM Browser Wallet, making it work more similar to MetaMask.

As part of the IOHK contractor's engagement, Cesar was a pioneer of the PRISM SDK, using it for building the Atala PRISM Credentials Verification Portal, which allows people to verify the authenticity of a Atala PRISM credential by uploading/pasting such Verifiable Credential into the portal.

He also built the Atala PRISM Operation Tracker, a Verification Portal component that allows people to track an operation submitted to Atala PRISM, displaying when it gets confirmed/rejected by the Atala PRISM network.

His contributions to the Atala PRISM team became essential tooling for the internal and external teams working with Atala PRISM.

Links:

• https://github.com/gurrion
• https://www.linkedin.com/in/gurrion

If you are funded, will you return to Catalyst in a later round for further funding? Please explain why / why not.

I'd likely try again. I feel like this project would be vital for gaining adoption for Atala PRISM.

Please describe what you will measure to track your project's progress, and how will you measure these?

We'll handle everything publicly, from the backlog to the milestone releases.

We have prepared a detailed timeline which we'll put into a Kanban board, such a board will allow us to easily understand the project state.

What does success for this project look like?

I'd define success if:

• We get the application shipped to the main web stores (Chrome/Firefox/Safari).
• We get at least one external developer committing a fix/change to the project every month.
• The application starts being used by individuals once PRISM works on mainnet.

Please provide information on whether this proposal is a continuation of a previously funded project in Catalyst or an entirely new one.

This is a new proposal.