The Jolocom team had the wonderful opportunity to attend the MyData 2017conference in Tallinn and Helsinki. Throughout the three days and two cities, many interesting and meaningful conversations were held between like-minded people. We’ve decided to share the more interesting conclusions and revelations that occurred to us during the event.

This effort will most likely span across a number of blog posts, each starting with a brief description of the idea itself, followed by a more elaborate analysis of the topic, and the relevant tangents.

It is also worth mentioning that throughout these posts the word “decentralization” will be used frequently, to describe both technical architectures (almost interchangeable with “distributed”), and ownership, legal or otherwise (namely whether a particular entity has full control over something).

Brief introduction

It is hard not to notice that the topics of self sovereign identity and data ownership are becoming more and more popular. While many are busy debating the exact meaning behind these terms, others are busy implementing new, intricate identity systems. The exact reasons behind the aforementioned surge in popularity are not easy to pinpoint, but they definitely are related to, at least partially, the growing hype around distributed ledger technologies, and particularly blockchains. Another factor is perhaps the looming GDPR panic, and the growing concern the general public has for the topics of privacy and data ownership.

Decentralization and trust are not binary

Given the aforementioned factors, it is not surprising that numerous projects and initiatives that strive to build better identity systems are emerging. Generally, all these initiatives try to solve a similar core problem, namely providing their users with an useful and decentralized self sovereign identity solution that requires as little implicit or explicit trust as possible between all interacting parties.

One thing that became apparent during the conference is that the concepts of trust and decentralization are not binary constructs. A system can be centralized, decentralized, or be placed on a million points between the two extremes. Decentralization can also happen at multiple layers. A system might, for instance, have all of it’s core logic delegated to smart contracts running on the public Ethereum blockchain, it’s underlying data storage provided by IPFS or Swarm, but the registration and allocation of unique identifiers for new users regulated by one central authority. This is not necessarily a bad design, and depending on the requirements and use cases, a system like this might make a lot of sense.

Decentralization can also happen in different areas. A system can be decentralized from a technical point of view, but operated and be solely supported by (and therefore fully dependent on) a legal entity, such as a corporation or foundation. Depending on the way the legal technicalities and licensing are set up, the failure of the entity might lead to the demise of the entire underlying system.

The aforementioned points make it difficult to unambiguously state how centralized / decentralized a particular system is. We are dealing with a multidimensional, continuous spectrum, that spans across a number of contexts. As an immediate result of that, we often find the answer to the question “How decentralized is this particular project’s architecture and its implementation?” to be “Well, it depends.”

Another aspect worth taking into consideration, is that different people, communities, and organizations consider different levels of decentralization acceptable. A company might be building an identity platform that is close source, relies on a permissioned blockchain that only the company itself or it’s partners are allowed to append data to, and use proprietary protocols, but still claim that they are building a decentralized, self sovereign identity solution, and as far as they are concerned, they are telling the truth. It’s up to each user to decide exactly what point on the decentralization spectrum they find acceptable.

Why settle for less?

One might wonder, why would I, as a user, settle for an identity solution that has a number of clearly centralized elements, when more decentralized alternatives are given? If we ignore the existence of network externalities, then most of the time the causes end up being related to ease of use, convenience, and the feature set I am provided with. Centralized solutions tend to be intrinsically easier to use and to develop. It’s faster and to roll out new features when you have control over all moving pieces in your architecture, and don’t have to concern yourself with consensus issues or with your users choosing to reject the new feature and remain on an older version of your application.

If your solution is fully based on a public blockchain, such as Ethereum, then the development team suddenly faces a plethora of new UX challenges, namely clearly explaining to it’s users why they have to pay for some operations that are usually free (e.g. updating the last name or email address associated with their profile), why there’s a certain delay on some operations, why do they need to remember 12 words, and why can’t their account be recovered with an email just like with any conventional service. Of course these challenges pose a great opportunity for both developers and UX designers to come up with new, brilliant, solutions and flows to onboard, and guide their users. But this task is far from trivial, and it’s importance should under no circumstances be underestimated.

Compromising

It is hardly debatable that a very well designed, fully decentralized identity solution will be slightly less user friendly, or at least way more challenging to build, than a very well designed, fully centralized identity solution. Therefore, developers are often required to make compromises when building their systems in order to get the best of both worlds.

Since different teams have different ideas and ideals, they chose to compromise in different ways and find different trade-offs acceptable. This leads to the existence of numerous projects that span all across the aforementioned centralized / decentralized spectrum. What we might end up with is an ecosystem of identity solutions, that are fundamentally similar in their intention but different in their implementation. One very important goal to keep in mind is to design these systems in a way that will allow for interoperability, and perhaps even data portability. We should at all costs avoid creating new data silos in the process of building these solutions, otherwise we’re back at square one.

But this is perhaps the topic of another blog post.