MyBit — Identity Verification for the Blockchain

Over the past couple of months MyBit has been taking steps to become a Decentralised Autonomous Organisation (DAO). Eventually, the organisation will live entirely on the Ethereum blockchain. All decisions, from issuing bounties and payroll to managing the MyBit Go platform, will be made through voting on the MyBit DAO. The Aragon platform is fantastic for creating DAO’s and they’ve done a lot of great work to create an extensible framework for upgrading DAOs with custom apps. We have already built a handful of custom apps for our organisation and we expect we will be contributing more towards their ecosystem over the coming months.

It quickly became clear to us that we needed to create some custom solutions for our DAO because one of the problems we see with many DAOs is the idea that one ERC-20 token should equal one vote. This is a similar structure to how corporations select a board. The person with the most shares has a bigger voice than anyone else. Organisations like this can easily devolve into plutocracies. If an individual owns 51% of the shares, it’s a democracy in name only — that individual is essentially a dictator.

At MyBit we want any user to be able to have a voice. We want it to be as simple as locking a single MYB token to receive 1 vote. We also want to balance that ideal with the notion that the people who are financially committed to the organisation should be able to have more of a say in it’s direction — but only to a limit. Currently we’ve set that limit to 13 votes. If a user has contributed to our ongoing token distribution and has locked 100,000 MYB for 3 years, they are entitled to a max of 13 votes in our DAO.

But this setup creates a new problem for us. What if one decides they want more than 13 votes? Creating Ethereum addresses is easy. Say there are a total of 50 voting shares, one just needs to create 51 Ethereum addresses, send them 1 MYB each, lock them in the DAO to receive voting shares, and then they can vote to send all funds to one of their addresses. Easy.

So how do we prevent this? We need some way of restricting access to the DAO to one Ethereum address per person.

We need an identity solution.

Luckily for us, there are an incredible number of companies providing some sort of identity solution. And for good reason — major hacks of personal information are a regular occurrence, and it seems every tech giant is engaged in some form of surveillance capitalism. Clearly, companies should not be trusted to be the stewards of our personal information. There are plenty of organisations both within the blockchain space, and outside of it, that are offering identity solutions. We have uPort, Civic, Blockstack, 3Box, BrightID, Estonia’s e-Residency and many more. But before we can choose an identity solution, we need to define our identity problem. What is it that these companies hope to solve? And how do we choose the solution that fits our needs?

First of all, what is our use case?

Our requirements for an identity solution are pretty basic:

1. We need to ensure that one person only equals one Ethereum address

2. We need that information available to a smart contract in the form of a whitelist

Under the umbrella of ‘identity’ we have several overlapping concepts that we need to discuss to get a handle on what each identity solution offers. These are the following: authentication, sovereignty, social verification, know your customer compliance (KYC), and Sybil resistance.

Authentication

The purpose of authentication is to restrict an account to the person who created that account. This way, only the account owner may tweet under their Twitter handle and only they may send funds from their Ethereum address. However, authenticating under one account doesn’t stop them from authenticating another account. They could conceivably have hundreds of Twitter handles or Ethereum addresses. All authentication does is ensure that they have permission to make changes under that particular account.

We see authentication as a service all over the web. Think about when you sign into a web app, you are given several options to Sign In with Facebook, Twitter, Google, GitHub, etc. In the future you may see more apps letting you Sign In with uPort, Blockstack, Civic, or MetaMask.

Authentication providers: Ethereum, Civic, uPort, Blockstack

Self-sovereignty

The idea of controlling who gets access to your data is what most people are talking about when they offer up blockchain as a solution to the surveillance capitalism of firms like Facebook and Google. The identity service stores personal data on your device in an encrypted form, and that data can be signed by a trusted authority who attests to the validity of the information. The user can then give permission for third-party apps to view the data. Additionally, these identity services provide a canonical source of information about you. When you change your username or update your status, all apps that reference that data are updated too. However, while this may protect some data, it still allows a platform to control exclusive access to your transaction data and social graph within the platform (e.g. likes, upvotes, messages, friends, followers, etc) which is arguably more valuable to advertisers. Additionally, once your personal info is given out to a third-party, that entity can do whatever they want with it, including storing it in their personal databases and using it for advertising.

Again, a user may want to have multiple identities. There is little way of verifying that the identity is unique or accurate unless you have attestations from trusted third-parties such as a nation state, municipality, or bank.

Sovereign identity providers: 3Box, uPort, Blockstack

Social Verification

A way of connecting identities on various platforms is through the use of social verification. Essentially, a user on one platform can verify that they control an identity on another platform by writing their ID from the first platform in a message on the second platform. For example, in 3Box, if someone wants to associate their Twitter handle with their Ethereum address, they write a tweet containing their Ethereum address. Then point 3Box to the tweet containing their Ethereum address. Now their Twitter handle shows up on their 3Box profile.

Of course, nothing prevents someone who is committed to creating multiple Ethereum addresses from also creating multiple fake social media profiles. But generally, for people who are engaged in social media, this is a nice way to check whether an address is associated with a real person. Aside from some sophisticated manipulation, its usually pretty easy to tell when you’re looking at a real account vs sock puppet. Unfortunately, relying on this method excludes those people who want nothing to do with social media for privacy, cultural, or social reasons. Additionally, this presupposes that these social media platforms are the arbiters of our online identities, and that’s a privilege that we don’t feel should be handed to them so willingly.

Social verification providers: 3Box, Blockstack, Keybase

KYC

Know your customer and anti-money laundering rules are a requirement of many jurisdictions for platforms that provide banking or securities trading services. For an individual to use these services they must provide proof of their legal identity to the platform. The only acceptable proof are legal documents issued by the national or sub-national government who has properly vetted the individual. Aside from identity theft or the faking of documents, this is an acceptably high standard to ensure a person is who they say they are. Although KYC identity providers are trusted centralised government authorities (sacrilege in blockchain circles!), it allows us to be confident that the account’s profile accurately represents an actual person.

However, KYC solutions aren’t exactly a perfect fit for what we need. First, even though any given ID (such as a uPort Decentralised ID) can be associated with an actual person, it doesn’t necessarily mean that the given ID is that person’s only ID. Depending on the service they could create multiple IDs and give the same legal documents for each. Second, services such as Estonia’s e-Residency program require you to verify yourself at an Estonian embassy which may be impossible for some people. Third, services such as uPort (via City of Zug) and Civic seem to only provide verification to certain municipalities/nationalities. And finally, we don’t believe any of these services provide attestation of a unique legal identity within the blockchain. If we used these services we’d still need an oracle that would check the verification and update a whitelist on the blockchain.

KYC providers: Nation states/Sub-national states, Estonian e-Residency, Civic, City of Zug (uPort)

Sybil Resistance

A Sybil attack is when an adversary attempts to influence a network via voting mechanics by creating many identities. If some amount of power is bestowed upon an identity (such as a vote), there is an incentive to create multiple identities to magnify one’s own power. If the network does not restrict identity creation it can be soon be taken over by a hostile actor. While this may not be catastrophic for a social network, it would be for a DAO that holds all operation funds.

This is the main reason we need an identity solution.

However, most identity solutions aren’t interested in solving this problem. They avoid the hard problem of identifying an individual person by creating a representation of them within their database or blockchain. That representation now has a name, profile pic, and other metadata and begins generating transactions. But, because there is very little to connecting the identity to the real person, we can create multiple identities with little restriction. This inevitably leads to sock puppets, bots, and trolls. Meanwhile, KYC requires that the account’s profile matches the owner’s legal identity, and this is solved by verifying the legal documents provided by a jurisdiction. However, for our purposes, we have no need for such information. From the perspective of our DAO, it doesn’t matter what your name is or where you’re from. So concepts of self-sovereign identity or KYC don’t actually apply. Additionally, since all authentication is handled by an Ethereum key pair, we just need a method of ensuring that an individual can only interact with the DAO using a single Ethereum address.

There are several identity solutions that could offer Sybil resistance. The City of Zug (via uPort) and Estonia both offer electronic verification of a person’s identity. However, we are unaware of any uPort third-party solutions that offer identity attestations globally and the Estonian e-Residency program requires people to jump through too many hoops to be viable for our use case.

Another new project, BrightID, takes a clever approach by doing graph analysis on an identity’s friend network and giving each user a score based on that analysis. But, like most networks, BrightID is only valuable when lots of people use it. So although it may be great in the future, its not useful to us right now. Also, it is not clear how BrightID prevents a malicious actor from creating a fake social graph using bots. However, if they solve those issues, BrightID could be a great solution down the road, especially if you need to verify identity at scale without requiring users to submit government documents.

Sybil resistance providers: BrightID, uPort attestations, Estonian e-Residency

Our Solution — MyID

Ultimately, we came to the conclusion that no identity solution is fully able to solve our problem and we would have to come up with our own solution. MyID will provide the secure yet flexible solution that we need for our ecosystem.

Fortunately, we start off with some great advantages that other solutions don’t have, namely a DAO made up of people with an incentive to keep bad actors out. So if we can rely on DAO members to do identity verification, it is as simple as initiating a vote to add the person’s Ethereum address to a smart contract whitelist. But this begs the question, how do we verify user’s identity in the DAO? We can’t rely on users to post their government IDs on the open web, that would be a privacy violation. We could possibly depend on verifying users via their social media accounts. However, as mentioned earlier, there is the possibility of people making sock puppet accounts and it does exclude people who are not on social media. In the end, we got inspiration from Reddit AMA’s.

You may be familiar with the strategy. A Reddit user needs to prove they are the person they claim to be. So they take a picture of themselves holding a piece of paper that shows their Reddit username. We’re taking the same approach. To join the DAO a user needs to show the person behind the Ethereum address. Its as simple as taking a picture of themselves holding a piece of paper that includes their Ethereum address. The picture and optional social media links are saved to IPFS and the IPFS hash is written to our contract. After that, it is easy enough for current DAO members to look at the faces of approved addresses and see if that person has already been approved. If they haven’t previously been approved, a member may initiate a vote. Upon approval by the DAO, the requester’s Ethereum address is included in the whitelist.

There are some advantages and disadvantages to this system. First, we don’t have to write any complex algorithms or rely on any third-parties to handle identity. By relying on our users to verify identity, we have the flexibility to adapt to edge cases and make assessments that no program would be capable of. On the flip side, this system would break down if we had to verify hundreds or thousands of identities.

In terms of scaling issues, we don’t see much cause for concern. We don’t expect the DAO to be very large, and the more people there are, the less incentive there is to engage in the vote. For example, if you look at Aragon’s DAO you can see that only a small percentage of ANT token holders actually vote. If scaling does become an issue we can look into solutions using facial recognition to filter for possible matches so that we don’t over-burden voting members. But ideally, it would never come to that. Scale too large and you have to develop a much more complex formalised governance structure (e.g large corporations, governments). By keeping our DAO small we will be better equipped to coordinate among our voting members using our current social media channels (Basecamp, Telegram, Keybase, etc).

We would love to hear back from the community with any concerns or suggestions. In particular, we’d like to hear any thoughts you have about scenarios where this system might fail, and we’d like to open up a dialogue with the community on possible solutions.

You can check out our test DAO on Rinkeby at https://rinkeby.aragon.org/#/0x13ab94f2cb92A395D8dD73638c74d27Ae397868B/