Everything around Web3 and Community

I am a computer science student at the technical university in Darmstadt and work as a software architect at Ostakon GmbH.
This is the Under The Ocean community page where you can find projects run for the UTO community as well as personal stuff.
Feel free to contact me via frankthefish@undertheocean.net, but make sure to set up OpenPGP for private messaging.

Blog

The Problem with identities on the web

A friend of mine told me recently about his plans making an app like snapchat. The difference would be, besides not being overloaded like the original app, that it is required to meet in person and exchange contacts via NFC to register each other making it also a system, where you need to be "invited" by someone who is already on the platform.


The key is, that the whole account system should only run by asymmetrical encryption, aka public-key cryptography. By holding the nfc chips to each other the public keys will be exchanged and the picture-sharing can begin.
At least this was the initial idea.

"With this way sending and receiving pictures will be totally anonymous"

But then the concern has been risen that you can create a new identity (a new private and public key pair) for every new contact you register. With this way you can identify who has sent you the pictures by giving everyone an own "address". Gone was the whole anonymity (or to be more specific; pseudonym) aspect. You'd be able to identify the person from every incoming picture by checking which private key would decrypt the received picture and show the corresponding name you've saved with the public key.
It is like creating several addresses to your home and giving each person another address. If you receive post you immediately know from which person it is since you gave different the addresses to each person.

A solution would be to create accounts and identify those with an email, or even harder to crack: with the phone number. But the thing about the project was that it has to work without accounts.

Of course in the above example you can see it also as a benefit being able to create identities easily, but we are here to look for problems and our problem here is that
we cannot guarantee that the sender hasn't got multiple identities and therefor we cannot guarantee that the sender stays anonymous.

Now how could we archive that?

The following topics are just notes and thoughts in which direction such a solution can go and are meant to think about some aspects, even if they are bad ideas, to our problem. So see them as inspiration to a potential solution.


The Multiple Identities Problem


Creating an identity consensus

An idea would be to have a network which has an identity consensus, just like the ledger in a blockchain system. Every person, which runs a node in the decentralized network would hold a copy of all identities (e.G. public keys of an asymmetrical encryption). Of course, such systems already exists. One of those existing solutions would be the IOTA Identity Framework, where you can create an identity, sign data with that, verify yourself and much more. It is decentralized, open source and the nodes can be run by the community.

Problem solved, right?

Just like in the problem above it is still easy to create multiple identities. What we need is something that says: this identity is legit and the person does not own multiple, different identities.
An idea for a solution would be to have reputation or a weight. The weight or reputation increases when the identity is being used and verified by other identities in the network.

As an example we take a contract we want to sign to start our employment at a new company. We call this person alice. The company, or the person of hr behind it, lets call him bob, writes the contract and signs it. Bob already has a large reputation or weight because he already signed a lot of things in the company or with other people. Bob is also older and his identity exists longer. With those to factors, Bob has a high reputation.
Bob now sends the contract to Alice and Alice signs it. This increases the reputation or weight of Alice's identity, because she is interacting with an identity which has a high reputation. Alice also knows, that the contract comes from a valid person, because she can check the reputation of Bob and vice versa.

Now, if Alice wants to create an identity just for the company, whatever her intentions are, Alice has to create a new identity. This identity will not have any reputation and therefore Bob as able to not accept the identity due of lack of reputation.

Unfortunately this concept introduces a problem:


Identity Mining

With the concept above, you probably had this thought: "Well, if I want my identity to have a good reputation, I'll create two identities and sign data for each other.". And you're right.
One of the goals of such a consensus protocol is to recognize such "mining bubbles".

A mining bubble



In the real world, identities will most probably interact with many different identities and not only with a just handful who only sign and verify each other. The protocol needs to differ between patterns of data mining and normal patterns. Therefor it also needs to implement a punishment system, which punished people who are mining those identities and interacting with those. The punishment would be loss of reputation, for example, or maybe in a system where money is involved, just like in blockchains, you can punish bad behavior by locking funds in a smart contract. This would require that every identity is backed up with some money, which is of course no problem in a blockchain scenario, in which smart contracts are supported. In this case you can even may faster increase reputation if you have more money behind an identity. But this approach of course may support the concept of data mining again, so be careful with that idea.

You may think now, that it is a bad idea to punish those who are interacting with data mined identities, but it may only subtract the gained reputation plus a little overhead, so not much will actually be lost. Especially in an ideal scenario, where you interact with a lot of different identities, where you gain your reputation of a variety of people and not just one person, where you will lose everything.


Identity theft

Since you are in control of your own private keys and therefor your own identity, it is now way easier to steal identities, since it is just a bunch of numbers saved on your device. As soon as someone has access to your identity, it can sign data in your name, and you cannot do anything about it.

It is a huge disadvantage in such a system, because it requires the identity holder to be responsable with her/his data. And you and me know, this won't happen anytime soon. It is a reason why banks and such central instances are still a big player. For example in case of loosing your credit card, you can always go to your bank and block your card to avoid any further damage. In such a system like this, you do not have such an option like this.

Here might come recovery keys in handy. A key or a list of keys which are accepted by the protocol, which are in relation to the initial private key, so that if they are being used, the old private key is not being accepted anymore by the network.

Such a structure may look like this:

The master key would grant access to all the other available keys. Of course, you want to save it good and secure. But in this case, you're able to extract key #0 and load the identity to your phone or notebook. If your phone or book gets hacked or gets stolen, and you're not sure if Eve has access to your identity, you can always go and get the next key in your list and deactivate your last key effectively. Of course these keys has to be related or known to each other.
A possibility would be to upload the corresponding public key tree and therefore as soon as you sign data with the private key #1, all upcoming signed data from key #0 will not be accepted anymore. You may be able to do this by especially calling a function which deactivates key #0 if the function is being signed by key #1. The protocol is able to check this, since in the public network, everyone knows the public key tree and is able to verify the data by themselves, but noone, but the person who owns the private key tree, can sign it.
Of course having a rolling key where you can just upload the new public key would be nicer, but I do not know a public/privat key system, where you can calculate the next public/private key out of an existing key. Let me know if there is such a thing!

Conclusion

So as you can see it is not that easy to truly identify without relying on a centralized instance like a company, who validates you or the government (In Germany you get an eId when requesting a new physical identity card). Both of the systems are not transparent and might be involved in corruption or can't even afford such services (Let it be the government or the company).
Creating such an identity framework is not easy but essential for a web3 future. There are already solutions which do a great job providing tools for such a framework, but it is not perfect yet. We are heading in a good direction though.

If the web has solved the multiple identity problem and if it is being used nearly everywhere we would have to effects: First of all, the value of data will rise dramatically because every dataset is backed up by a proofed identity. It'd give the data industry a huge step forward, especially the AI industry. But this leads to another point of such a system: Privacy. Such a framework still needs to let you have control over your data. More than traditional systems. We need a framework which lets chosen people or instances access certain data and restrict the rest of it.
A nice example would be you patient file: You only want it to let it be seen by the doctors you go to, but not everyone else.

So the ideal situation would be that the industry has more valuable data and the people more control over their data. And all that backed up with a transparent, community driven network.