uPort: The Wallet is the New Browser

Many people feel user-owned identity and data will be crucial for realizing the compelling vision of Web 3.0. uPort will act as a unique and user-controlled perspective on the blockchain based upon the persona(s) of the user.

ConsenSys internally released a web-based wallet and identity management system — uPort — during our first ‘persona week’ — a period of concerted discussions about wallet, identity, and persona amongst all of our developer teams. While the wallet system is still in its early stages, we have started to integrate an ID and persona construct across all of our dApps. Soon a uPort persona will enable access to any dApp ConsenSys or other developers build. ConsenSys has begun efforts to work with various partners towards standardization of these components.

Since all data on the blockchain is public, the identity of the user in their uPort is determined by their public/private key pairs that give them access to certain information. This perspective, and the sharing permissions of other addresses, determines what users will see in their uPort dashboard, generating a unique viewpoint for every user. In many ways uPort and other wallet systems will replace the browser for the next generation Internet, enabled by distributed technologies like Ethereum.

At this first MVP stage of uPort we can think of Personas as an Ethereum- based version of services like keybase or onename. It will associate an Ethereum Address with a Name and Profile Picture, and potentially other info like email address, Twitter handle, etc., in order to map an identity to various attributes. (At first we will start with Name and Picture, but we intend to follow the Blockchain ID spec for other data). This first stage of Persona is primarily visual, as it allows us to replace an address with a Persona badge showing a Name and Picture.

The second stage of Persona will focus on having a Persona Identifier, which means even if the user loses their private keys or has their private keys compromised, they will be able to restore their persona. A “multisig” system will enable this, where each persona can select 2 delegates. In the event that one loses control over the key(s) controlling the Persona, these delegates can reset the keys to bring the persona back in control.

This will also enable a persistent reputation attached to that Persona, that can attributed and understood in a variety of contexts. Keep tuned for future posts on our reputation system.

Technically what is uPort?

We’ve created an initial MVP of Persona contracts. The contract contains

• The address that created the contract — this is the Persona Identifier
• The name of the Persona (in IPFS)*
• The profile picture (Avatar) of the Persona (in IPFS)

We have a bare-bones website where people can create a web-based wallet and use this to create a Persona on the ConsenSys testnet, and get back the address of the contract. We are using a testnet faucet, as well as a simple registry, to map the user’s address to the contract address of their Persona.

*The reason we are using IPFS to store data is that when we start adding more data it will be too much to store on the blockchain, and already with a profile picture it’s already too much if the picture is large. For the information in IPFS we are following the BlockchainID specification (v0.2) here.

Next UX/UI steps:

• skin a “persona” module home page which gives a light intro to what a user is about to do when they create a persona, and what a persona can do (essentially Christian’s demo).
• Placeholder for “uPort”, a persona “dashboard”: begin mockups of a potential interface for the management of multiple personas.

These ideas are still being formed and digital identity/persona is a vast project. Some open questions include:

• What’s the schematic relationship between a user, their “dashboard”, and their various personas?
• What’s the best way of packaging the Persona functionality up into a module that can be easily used in different Dapps? Dapp developers should ideally not have to worry about low-level IPFS details for instance.

This was written by Christian Lundkvist, Lead Product Developer at uPort. With special thanks to Ainsley Sutherland, Joseph Lubin, Ashley Taylor, and the ConsenSys Team. If you have any questions, email us at team@uport.me