DECENTRALIZED IDENTITY AND REPUTATION

INTRODUCTION

Identity is who you are and what others think of you (which is in many cases a more honest view than what you’ll say about yourself). In the offline world, I can prove I’m Spanish by showing my Spanish ID. It has been issued by the Spanish government, who are the only ones who can say who’s Spanish and who’s not, and it’s been designed in a way that can’t be forged (or at least it’s very difficult to do so). Also, the ID shows a photo of myself that everyone can check. If they need to be completely sure, there are fingerprints associated to me that they could double check with the Spanish government to ensure completely that I’m the right holder of the document. As a result, when I show it, people just believe I’m Spanish.

So the Spanish ID (or any other country’s) works because only the Spanish government can issue it, because they’re the ones who can state who’s Spanish and who’s not, and because no one can use another person’s ID. Therefore, in general IDs work if:

CARDS

How to bring this offline experience online? It’s all about introducing a kind of wallet or purse which can hold a number of “cards” that say something about you and whose involved actors can’t be impersonated.

An example of card you might want to keep in your purse is your Traity reputation. If you’re Traity Gold you might want to tell other people about it. It’s easy to model this card using JSON and asymmetric cryptography:

{
  "key": "reputation",
  "value": "gold",
  "holder": "3v4rn49nct4y4h9nv" (this is Alice's public key),
  "issued_by": "a1cd2cdvf34vbgf56" (this is Traity's public key),
  "issued_on": "2015-02-01",
  "signatures": {"a1cd2cdvf34vbgf56": "2bcrt84brc392bc6293bct49nc83"}
}

There are a couple of fields: a key, a value, the card’s holder, who issued it, when it was issued and a set of signatures. These signatures are the cryptographic magic that lets this card be verifiable by itself. Only the owner of “a1cd2cdvf34vbgf56”’s private key can sign this JSON object. Therefore, to verify that this card object is legit, I only need to have the JSON object, and know that “a1cd2cdvf34vbgf56” is Traity. Also, Alice is shown as the card’s holder. This means that no one else can get that card and claim they have gold reputation, but only Alice.

Another example is a trust relation. Imagine Bob trusts Alice. He could issue a card that says so, so that Alice can tell the world that Bob trusts her:

{
  "key": "trusts",
  "holder": "3v4rn49nct4y4h9nv" (this is Alice's public key),
  "issued_by": "bcr348c6283bcr625" (this is Bob's public key),
  "issued_on": "2015-01-31",
  "signatures": {"bcr348c6283bcr625": "69cb367bc2369bct63492bc69bct"}
}

Here, Bob is issuing a card that only Alice can hold, which states that he trusts her. By using cryptographic signatures, only Bob can issue this card.

Also, be aware that your online identity is still slightly different from your offline identity in a couple of ways: you can claim some attributes about yourself, like your name, your picture, or your description. There’s no third party issuing these facts, as you’re free to name yourself “Cookie Monster” and have this picture: http://pixieknits.bloggnorge.com/files/2015/02/cookie-monster.jpg . A card about your name could look like this:

{
  "key": "name",
  "value": "Cookie Monster"
  "holder": "3v4rn49nct4y4h9nv" (this is Alice's public key),
  "issued_by": "3v4rn49nct4y4h9nv" (this is Alice's public key),
  "issued_on": "2015-01-31",
  "signatures": {"3v4rn49nct4y4h9nv": "n495y2nvty4593nty3789m27083d"}
}

In this case, this card says that Alice self-claims that her name is “Cookie Monster”. She can carry such card anywhere in her Traity purse. At anytime, she can give it to Bob, and Bob will know that she’s decided to be known as “Cookie Monster”, as she’s the only one who was able to sign that card.

YOU OWN YOUR IDENTITY

Alice can decide what cards she’s carrying in her purse and whether to show them or not, like IDs in the offline world. Whenever she wants to get a better insurance, she would show her gold reputation card and be offered a cheaper insurance price in an e-commerce. She could also prove that Bob trusts her, and show her Bob-trusts-Alice card to Charlie, a friend of Bob, so that she’s trusted by Charlie too.

You’d notice this is incompatible with cards with negative judges. If Alice was given a card that says something bad about her, like “Bob dislikes Alice”, she wouldn’t store it in her Traity purse, and would never use it (as what a use could that have if it only conveys a negative fact about Alice).

No one can force you to carry a “negative” ID with you. Similarly, if you’re supposed to own your data, no one can decide for you what cards you have to keep in your Traity purse and which ones you have to show anywhere.

Does this mean negative judges are not possible using these concepts? Not exactly. It can be agreed that cards have an expiration date. This way, you might be Traity Gold in the past, but not anymore since you screwed up with your neighbour while walking her dog. You won’t have a new Traity Gold card anymore since then. Also, Bob might decide to stop trusting Alice, and his Bob-trusts-Alice card won’t be renewed.

WHO’S WHO?

We’ve outlined the concept of cards and how they define your identity by letting you communicate what you say about you and what others say about you in a safe way. However, there was one open question when verifying a card: we said you need to know that “a1cd2cdvf34vbgf56” is Traity. How can I know that “a1cd2cdvf34vbgf56” is Traity? And when finding a Bob-trusts-Alice card, how can I know that “bcr348c6283bcr625” is Bob?

Of course, if I’m a doorman who’s only letting people with gold reputation through, I would be trained that the “traity-reputation” type of card can only be issued by “a1cd2cdvf34vbgf56” (whoever that public key belongs to, be it Traity or anyone else). But what if there were multiple providers issuing “traity-reputation” cards?

And what about Bob, the guy who’s endorsing Alice? Who the hell is Bob?

Whenever identity is based not just on what you say about you, but on what others say about you, it appears the need of being able to access other individual’s identity to verify the identity of the first one.

Until now, we’ve spoken about Traity’s purse and about the fact that Alice can have this “purse” with her and store a set of “cards” to prove some statements about her identity.

But now we’ve felt we should check the identities of the individuals who have issued cards that Alice is using to define her identity.

And, indeed, what we’re doing is questioning Alice’s reputation.

REPUTATION

Reputation is the opinion that others have about a person or thing (according to Random House Learner’s Dictionary of American English). We’ve noticed there’s a reputation problem when dealing with the card system outlined above because we’ve talked about public keys making statements about other public keys.

So basically, we don’t want that Bob is a fake individual that has been created by Alice to falsely have a friend who trusts her. And we don’t want that the entity who signed her reputation level card was created by Alice herself for her own benefit.

To solve this problem of trust there are basically two options:

The first approach would mean, e.g., assuming that “a1cd2cdvf34vbgf56” is Traity, and that every individual who can show they are Traity Gold, can be trusted. Or stating that “bcr348c6283bcr625” (Bob’s public key) is trustworthy, and that we should trust him and his statements.

The second approach means, e.g., that we can analyse Alice’s network, check Alice’s interactions, and conclude that Alice’s behaviour is reasonable by applying some heuristics without assuming that any particular individual in Alice’s network can be trusted. For instance, we could check that Alice has more than 100 cards and that they are 10 years old (we’ll see later on that we can trust the cards’ age).

Naturally, both approaches can be combined, and this way we could quickly validate Alice’s identity using heuristics if we trust Bob and Bob trusts Alice.

Heuristics should definitely take into account dates and times, the number of interactions, and the reputation of other individuals interacting, but such algorithm might evolve with the time getting better and better.

DECENTRALISED REPUTATION

Whatever this reputation algorithm is, it has a constraint because of users’ privacy. Alice, Bob, Charlie, etc. might not want to share all their cards every time a party wants to check their trustworthiness. That’s why a verifier entity like Traity makes sense (Alice only needs to show her reputation card instead of sharing all her data).

But then, do we need heuristics at all if we’re trusting one party to do all the background check? That’d be federated reputation (i.e., a scenario where you can choose what reputation verifier use), but is it possible to provide decentralised reputation (i.e., a scenario where anyone can verify an individual’s reputation)? It makes sense to look for a solution that doesn’t require a third party to know all data from users to make the verifications.

There’s only one solution, which is keeping certain cards public so that anyone can verify reputation easily. For instance, Bob-trusts-Alice type of cards could be public, making the eigentrust computation available to everyone.

However, Traity’s reputation computation would always be more accurate, as it’d be able to take into account more data than just public data. Additionally, at bootstrapping time there’re no cards around and no blockchain data about anyone, so everyone has zero distributed reputation as of today until we bring data from social networks or from the offline world to the users’ purses in the form of cards.

STORAGE

Where would all these cards be stored? I.e., how should Traity purse be in terms of technology? The requirements for this storage are: (1) Alice should be able to store and remove cards as desired (2) Alice can decide to keep her cards private (3) Cards’ issue date can’t be faked

Alice’s hard drive is enough to achieve (1) and (2). However, nothing stops Alice from generating cards that appear to have been issued at any point in time using self-generated key pairs.

An external server could work to achieve (1), (2), and (3), but how could we trust that this server has not been set up by Alice and that she can still self-generate key pairs with fake cards issue date? In other words, why should we trust that the server is not generating new fake cards with arbitrary dates?

The only solution is introducing a truly independent party that can be trusted by design to store the proper cards issue date. One solution is blockchain (Bitcoin’s, Ethereum’s, or any other), whose transaction history can’t be changed. We could use blockchain to store Alice’s cards hashes whenever they’re issued so that the issue date is the date the card was stored in the blockchain. A hash is a string that identifies a card, without revealing the card’s actual data (given a card, you can get its hash, but you can get no card given a hash). Alice might be free to throw away cards or create new ones, but she cannot fake a 10 year-old history of cards unless those cards where really created in that period of time, as they’d be in the blockchain in that case.

Blockchain enables using any server to store data, as the server doesn’t have to be trusted because (1) cards can be removed by Alice any time, (2) they can’t be created arbitrarily thanks to cryptography, (3) the privacy issue can be left as a problem between Alice and the server of her choice, and (4) cards’ issue date is handled by the blockchain (i.e., every card that is not in the blockchain should be considered invalid even if it’s properly signed). The architecture still allows storing non-sensitive, public data in the blockchain so that no servers are needed.

SAMPLE SCENARIO - LOGGING IN

Imagine using this identity architecture to log into a website called Shareadragon, where you can find a walker for your dragon. Shareadragon’s founders want only quality users in their site, because when doing dragon walking, users are looking for trustworthy people to give their dragons to.

Because of this, they’ve integrated a “Log in with Traity” button, which uses Traity and, therefore, Traity purse as well. This way they can: (1) Let Shareadragon users own their data (2) Enable their users use their Shareadragon data in other sites (3) Background check users using Traity’s reputation cards (4) Background check users based on the public data they have in their Traity purse without the need of trusting any third party as verifier

The log in process works as follows:

Now let’s take a look at Bob’s case. The first four steps are the same as Alice, and then:

Let’s look at Charlie’s case now. The first four steps are the same as Alice, and then:

You can notice that the distributed reputation computation is not needed, but enables a working system without the existence of verifiers like Traity, enabling users like Bob, who don’t use Traity, to not be left apart.

SUMMARY

We’ve outlined a simple architecture for managing identity with the following ideas:

WHAT’S NEXT?

We’ll be open sourcing all the necessary tools to achieve this vision on identity in the following months.

We’re releasing our first prototype, where you can check how your Traity reviews are stored in the blockchain.

You can see the demo here and check the source code here