Persistent malevolent exploitations of our digital data suggest that there is something inherently wrong with how the current digital identity framework works. In the wake of such exposures, privacy—quite understandably—shifts from being an afterthought to becoming the main selling point. Because global problems require global solutions, there is an increasing push to build a new identity framework through standardization. Interestingly enough, the community leading this push has put blockchain and privacy at the forefront—two terms that are often considered by many as oxymorons.
Setting the scene
Shortly after it came into being, blockchain received hails and praise for its ability and potential to transform a great deal of our digital experience. However, alongside accolades, this technology has also faced widespread criticism, mostly for introducing many regulatory challenges and ignoring existing laws. Fast-forwarding over a decade later, such concerns have yet to be abated. Many legal uncertainties remain murky, prompting policymakers, academia, and industry to run boisterous debates regarding strategies for appropriate regulation.
Privacy-wise, common concerns relate either to blockchain’s near-immutability feature and the impending danger to limit data subject rights or to its disintermediated nature that makes the appointment of a responsible party to safeguard privacy a tall order. These and similar stress points have goaded blockchain sceptics to cultivate a school of thought that claims, among other things, that the technology is incompatible with safeguarding privacy rights and cannot coexist with stringent data protection regulations like the GDPR.
But recent developments within the standardization community may cast doubt on the veracity of most fears over blockchains invading our privacy. For quite some time now, computer scientists have been shouldering the brunt of burden to incorporate privacy and data protection principles in the design architecture of this novel concept of blockchain-powered decentralized identities. So how far have they come with their privacy-preserving efforts?
First thing’s first. What are decentralized identities?
Decentralized identities are a blockchain-enabled answer to conventional identity management meant to prepare the ground for self-sovereign identities. Such identities are created by an individual or organization and remain fully under control of the user without needing a centralized registry, certification authority, or identity provider. To make this identity framework possible and interoperable, the W3C is developing standards for Verifiable Claims and a new type of digital identifiers, known as Decentralized Identifiers (DIDs). Similar to email addresses, DIDs are globally unique identifiers—meaning that there are no two identical DIDs. But unlike email addresses, DIDs do not require a centralized registration authority in the middle. Instead, they rely on blockchains to provide the root of trust.
This still doesn’t tell much. Putting things into perspective, the current and dominant online data model requires users to continuously reassert and reverify their identity with an unprecedented number of service providers. This is normally done by either creating custom credentials (e.g. usernames and passwords) each time users sign up for new online services or by utilizing centralized third-party services such as Facebook or Google single sign-on options. The idea behind DIDs is to remove all identity mediators and allow users to self-generate DIDs to which they can later attach identity claims—for instance, age, nationality, education, healthcare vitals, and whatnot. Proving these claims to third parties would require presenting attestations acquired from relevant trusted authorities that come in the form of verifiable credentials.
To see how this might work, imagine a simplistic scenario where you need to prove to the online merchant that you are of drinking age for purchasing alcohol. The corresponding offline way to do so would be to present to the cashier your driver’s license or national ID card. But while the cashier only needs to verify your age, you are also unnecessarily revealing many personal details at the same time such as your name, home address, and nationality. In the decentralized identity world, individuals have the chance to disclose only those pieces of information that are exclusively necessary for the specific transaction to happen while keeping other personal data private. Sending the credential that contains the user’s age would usually suffice for the said scenario.
Back to the privacy and data protection considerations
Blockchain data records typically involve the use of cryptography and often appear as random-looking strings of letters and digits. Yet, even that data has powerful capabilities to create a distinctive profile of an individual in combination with other information. Many correlation methods can reveal the identity behind public keys, hashed, or otherwise de-identified data on blockchains. Scholars have already discussed these methods in great detail elsewhere.
To counter such identification risks, the W3C in their development phase of the standards for DIDs and Verifiable Claims introduce several workarounds, some of which include the following:
- Instead of using the same DID for multiple or all interactions recorded on a blockchain, pairwise unique DIDs should be established for every relationship between two parties.
- Where a public blockchain is used as a DID registry, no personal data should be stored on publicly available DID documents. Rather, personal data should be kept off-chain under the control of the individual and only exchanged through private peer-to-peer encrypted communication channels.
- Credentials should be as abstract as possible, without revealing specific information about an individual. In the above scenario, the corresponding credential would only confirm that the individual is older than the required age by issuing ageOver verifiable credential instead of disclosing the actual birthdate.
- Attributes in credentials should be limited to the absolute minimum necessary—preferably a single attribute per credential. Driver’s licenses, for instance, can include the DID of the individual, the vehicle class, and the expiration date of the license, omitting other attributes normally contained in a driver’s license, such as height, weight, birthdate etc. If for one reason or another more attributes are included in a credential, then selective disclosure should be incorporated as an option for the individual to make decisions about what information they disclose.
- Verifiers should only request information that is necessary for the transaction to occur.
Guiding measures like these undeniably promote privacy preservation and reflect the philosophy of data protection by design and default. Indeed, one of the requirements in Article 25 GDPR is to implement, at the time of the determination of the processing mechanism and at the time of the processing itself, appropriate technical and organizational measures, one of which is pseudonymization. Because DIDs are in essence humanly unintelligible, establishing a relation to an individual based on the DID alone when one-time DIDs are used will be extremely difficult, if not borderline impossible, to carry out. Additionally, limiting attributes per credential and allowing selective disclosure appears to be in line with the data minimisation principle. Likewise, implementing the GDPR’s right to erasure won’t be that much of a problem if public ledgers are only intended to record DIDs of legal entities while personal data of natural persons is exchanged exclusively off-chain via encrypted channels.
Of course, this approach only scratches the surface. To paint the whole privacy spectrum image, a more detailed analysis is due. Standards are useful for setting guidance for global interoperability. But a lot more will be needed to be GDPR compliant when applying this verification strategy to real-world scenarios. Nevertheless, it is encouraging to see that there are solutions already out there that follow the letter of these recommendations and do not appear outwardly hostile to privacy.
The bottom line
Critics aren’t wrong about the risks that the use of blockchains can pose to privacy. But these risks aren’t any more concerning than the ones brought by other technologies. Rather than obsessively concentrating on the costs, public debate should also acknowledge potential user benefits to keep a more complete roster of blockchain’s privacy impact. Many technologies whose privacy implications our society fears can boost user privacy if given the chance by regulators and policymakers. Blockchains, as the proposed standards show, can evolve to attain GDPR compliance and simultaneously become privacy enablers.
For this reason, asking whether blockchains can coexist with the GDPR threatens to push the inquiry into an overly abstract dimension—one that is well-suited for science fiction but little else. Queries of this type can also incidentally promote a wrong narrative that portrays the EU as a blockchain-hostile environment. Even if raised out of entirely benevolent motives, they further display a collective blind spot that hampers our society from perceiving emerging tech as work-in-progress that can adapt to regulatory demands. No matter who gets to deal with such questions, one must always remember that it is the use of technology and not the technology itself that can run afoul of GDPR’s stark lines. The importance of this cannot be stressed enough.


Comments