It is one of the core functionalities of decentralized networks, and is what enables novel digital identity capabilities like “self-sovereignty” and “globally recognized proprietorship” (don’t worry we will unpack what these mean).
The ability to wrap value in smart contracts and prove individual ownership of a smart contract’s contents is a property that is truly unique to blockchain solutions, and is something that should be leveraged by all blockchain projects.
That being said, self-ownership of information is a very delicate piece of functionality that can often be misconstrued and misinterpreted.
Long story short: just because you can use a blockchain to prove ownership of information does not mean that you should use a blockchain to prove ownership of information.
Whereas users on central systems are subject to their data being under the control of centralized management, decentralized networks enable users to directly maintain all of their personal information.This is done through the issuance of a public & private keys, which ultimately tie users to specific identities on a blockchain.
These identities are not synonymous with the identities we are used to possessing on websites like Facebook, Google, or even PayPal, where each respective service plays a role in maintaining and storing our information. Instead, this issuance of a private key provides us a gateway to our own “self-maintained” identity.
With this personally maintained private key we can do things like transfer funds, move assets, or upload data — all under the hood of our own management.
This in itself is what gives blockchains the incredible power of circumventing regional or institutional borders. If I am no longer reliant on Google to store my data, I can do whatever I want with it. (Whether it be sell it, keep it, prove ownership of it, or more.)
Now, as with all good things, the use of a blockchain for this purpose comes with a number of important tradeoffs and caveats. The following sections are devoted to explaining the intricacies of making a decision to implement a self-sovereign identity service, boiling the process down to a key set of questions that are useful for use case ideation and concept planning.
This question was specifically chosen to be asked first because it provides a preface to all further questions regarding the use of a blockchain.
As previously discussed, one of the fundamental capabilities of decentralized systems is their ability to provide end users with total ownership over their information.
Any time I want to be able to verify my ownership of an asset (whether it be a house, a car, or a dollar), all I must do is prove my ownership of my private key, and the rest of the network around me can guarantee that that asset is mine. Nobody else has access to alter that information — only I have control over it.
In a centralized service, network constituents (users) are subject to the protection of their information taking place through a central party responsible for maintaining data on everybody (i.e Google stores your information and you have no real control over what they do with it).
An example of this can be seen in the world of land registry, where if I would like to prove that the land I live on is mine I would first have to consult with the American government who can then prove to someone else that I am telling the truth.
The problem with having a centralized solution in this case, however, is that the American government theoretically could have the power to assign my land to someone else (tampering with the system), or could have issues proving this fact to other entities (i.e the Chinese government could say they don’t recognize the fact that I own that American land).
This highlights some of the drawbacks and issues that comes with the centralization of information — issues that can be resolved with the proper implementation of a blockchain.
Now, after reading the above statements you may be ready to say that everyone should use a blockchain — right?
Well, in theory, the ability to achieve globally recognized ownership through the means of a blockchain is great for everyone, as with it comes a freedom from reliance on central entities to maintain and store data on any of its users.
There are, however, a couple of drawbacks that are associated with the issuance of self-sovereignty in any network.
These issues can be manifested into a core set of questions that will ultimately help guide readers to a concise answer on whether a blockchain is needed (at least in the technology’s current form).
Ok, so we are ready to develop a decentralized application. We code up a couple smart contracts, build a back-end and front-end, and are ready to start accepting users. The first user signs up for our platform, sets a username and a password, and then receives his/her public and private keys.
The first question once this happens — where are these public & private keys going?
The simplest path of action would be to store a user’s keys in the back-end of our blockchain solution. This way users account information is well-managed, and can be easily acted upon (i.e permissions can be granted and removed under our management).
An example of this can be immediately seen in exchange services like Coinbase, Bittrex, or Binance, whereby a users private keys are stored centrally on the exchange’s servers.
The problem with this approach is that by giving these exchanges access to our private keys we have unintentionally turned our solution back into a centralized service — as with these keys under their management they now hold the ability to access our accounts and transfer ownership if they so desire.
This kills the concept of self-sovereignty that blockchain solutions can offer entirely, as users can no longer say that their information is verifiably under their possession.
The alternative to this approach is allowing users to store their own private keys — re-unlocking the potential for globally recognized ownership. The issue with this approach is that the system is now out of the creator’s hands, in that we cannot provide any assistance to users who lose their private keys.
This presents an “Identity management dilemna”, highlighted in the following table:
Once we have made a decision on the storage of our users private keys we should then progress on to consider the format in which we are going to store our users data.
In today’s industry there is often a conflation that blockchains are tools for privacy, when, oftentimes, the opposite is the case!
In reality, blockchains are tremendous tools for securing value and demonstrating public ownership of information.
To explain this, think back to the land registry case from earlier. With a blockchain solution, users no longer need to rely on the American government to be able to verify the ownership of their land. Instead, because information is immutable and publicly viewable, users can personally prove this truth without the need for any central entity.
Unfortunately, because of this “open” nature of blockchain solutions, sensitive information can often easily be viewed by anyone on the network — leading to privacy and security concerns.
Now, there are work-arounds to these issues. Instead of listing data directly on the blockchain (or “on-chain”), platform designers can choose to first hash this data then put the data on-chain. Some systems will also encrypt the data on a user’s device (like a phone) and only present pieces of it on-chain when required. This provides users with a level of obscurity that grants some level of privacy — however, it cannot be said that this grants total anonymity.
While ownership itself cannot be copied, it should be assumed that a user’s ownership information has at least the prospect of being copied, as some variant of the information is out there for anyone on the network to see. The complete protection of information requires a central database: whereby a single entity can restrict read and write permissions to anyone on a network accordingly.
This last question is structured as a follow-up to our previous thoughts on the publicity of transaction information. Unfortunately, until tools like Zero-Knowledge Proofs and zk-snarks become common practice, blockchains are unable to allow users to completely privatize their ownership information, despite best attempts.
Information on blockchains should be considered semi-publicly viewable, and should not be assumed to completely secured from the reaches of any third parties interested in that data.
In keeping up with consistency from past articles, I have designed a brief checklist glossing over some of the core questions to ask regarding identity management before designing a blockchain solution.
As touched upon at the beginning of this article there are actually numerous blockchain applications out there that can greatly affect existing identity management systems for the better.
If we are able to progress our way down the above-pictured flow chart we are well on our way to having a sound blockchain use case, increasing our likelihood of providing the valuable identity management solutions for our distributed platforms.
Follow me on Medium or LinkedIn for more insight on how to invest in and understand blockchain projects from a VC, investor, and founder’s perspective.
Thanks to Petros Ring for providing feedback on this essay
