The Scope and Limits of Indy’s Privacy Tech

Guest post: Daniel Hardman, Evernym

Privacy is a hot topic in blockchain circles–and across the entire digital landscape. GDPR, ePrivacy, and similar regulatory regimes have the world thinking hard and smart. Modern systems must bake privacy into their DNA; it can’t be bolted on after-the-fact. I’ve written elsewhere about why this is true, and how it must be done–and I’ve spent the last couple years helping Hyperledger Indy embody all the privacy goodness I know. I’m encouraged to hear a swelling chorus of blockchain practitioners opine that certain things must NOT go on a blockchain.

Perhaps you have heard a claim that Indy “solves” privacy. Or perhaps you’ve seen skeptics roll their eyes, muttering about how we’re all going to be correlated by the surveillance state, no matter what we do.

The truth is that both of these perspectives distort reality. Indy does offer some wonderful features to aid privacy, and these features matter! But institutions are certainly going to know some things about us, no matter what Indy does. Indy can minimize this in exciting ways. Nonetheless, what privacy we have, now or in the future, will emerge from a combination of technology, social and legal constructs, market forces, and human behavior; it can’t be trivialized as a tech problem.

What “Privacy Tech” Are We Talking About?

Today, Hyperledger Indy’s approach to privacy includes elliptic curve cryptography, pairwise DIDs, semi-trusted agents, agent-to-agent communication using techniques such as libsodium’s sealed box and authenticated encryption, zero-knowledge proofs, a separation between credentials and proofs, privacy-preserving credential revocation features, an affinity for data and key storage at the edge, and a carefully constructed wallet interface that manages personal secrets with industry best practices. In addition, privacy-preserving agent (device) revocation has been demonstrated as a proof of concept.

Indy’s roadmap includes additional privacy-enhancing features such as a user-friendly SSI tool (mobile app) with smart and safe defaults, microledgers, sophisticated policy and/or AI for agents, mix networks for transaction submitting and agent routing, and so forth.

Some of these technologies exist in other identity technologies, but Indy combines more of them, in far more powerful ways, than any similar technology I know.

What All This Tech Does NOT Deliver

Except for people who live in remote, technology-scarce  places, all of us are constantly observed and recorded. Google maps may have a picture of our front door; cell phone towers track the location of our mobile devices; credit card companies see what we spend; closed-circuit cameras watch us on the road or subway.

In such an environment, much will be known about us, even if we use Indy to prove things in zero knowledge. And, if we choose to use Indy to disclose something identifying–our email or phone number or name+birthdate, for example–then the disclosing interaction is correlatable to a much bigger digital footprint, no matter what fancy math did the proving. Even less perfect correlators like first name + fuzzy place + fuzzy time may correlate us, given sufficient context.

It might be tempting to say, then, that there’s no point to Indy’s elaborate privacy posture. But there is more to the story.

What Hyperledger Indy Privacy DOES Deliver

Hyperledger Indy allows you to construct interactions where the degree of disclosure is explicit and minimal–much smaller than what was previously possible. Nothing about the mechanics of connecting, talking, or proving in Indy is leaky with respect to privacy; vulnerabilities that emerge must come from the broader context. No other technology takes this minimization as far as Indy does, and no other technology separates interactions from one another as carefully. If privacy problems are like a biohazard, Indy is the world’s most vocal champion of wearing gloves and using a sharps container for needles–and it provides the world’s best latex and disinfectants.

Of course, this does not give perfect protection. Like a needle stick, mistakes can ruin Indy’s carefully sanitized interactions, and contamination is always a possibility. In 2017, the layouts of US army bases in some of the most dangerous locations in the world were compromised because soldiers had been using the Strava running app to track where they exercised (https://wapo.st/2J6DQqU). If this can happen when stakes are so high, and when the organization is as careful as a sophisticated army, then similar fiascos will undoubtedly occur, both with and without Indy technology, for the foreseeable future. These are serious problems that are not to be underestimated.

Despite the imperfect guarantees, doctors consider it worthwhile–even vital–to wear gloves. And despite risk, Indy’s privacy tech can deliver real value, if we are careful about constraining behavior and understanding use cases. Any interaction that does not leak is a tiny bit of personal, private space–and chaining such interactions together can accrue significant benefits. Indy makes it possible to prequalify for a loan at a thousand banks, in a way that proves credit worthiness, income, and citizenship, without forfeiting privacy. Used correctly, it can insulate cautious whistleblowers; it can enable secure, private voting; it can make online dating safer. Many other use cases exist. In each situation, we must carefully assess privacy beyond the narrow context of Indy’s proving mechanics. Gloves are less helpful when a disease vector is airborne; the government still needs to know who you are when you pay your taxes.

Intentions And Incentives

Besides discussing what protections Hyperledger Indy offers on the technical level, and what ways there might be to defeat such protections, we can also make an argument that architectures, algorithms, data models, and cryptography always carry a certain “intention” towards the parties we interact with. In our case, this intention is to maintain the individual’s privacy, sovereignty, etc. Whether or not the technology can strictly enforce this intention, or to what extent, is an important question, but not the only argument for building it in a certain way.

If we use pairwise DIDs and zero-knowledge proofs, the message is clearly “don’t try to correlate me,” even if you could find a way to do it if you try hard enough. An HTTP Do-Not-Track header says “do not track me,” but it doesn’t offer any actual protection from tracking. The VRM community has been talking about user-defined terms for a long time. In a relationship, you can express “don’t use my data for advertising,” or “delete my data after 14 days,” or “use my data for research, but not commercially.”

Simply expressing these intentions in code and architecture has value by itself. It bears a message that privacy and sovereignty “should be honored,” even if it cannot always be guaranteed technically that it will be. Over time, we expect that through regulation, trust frameworks, reputation, and similar mechanisms, not honoring such intentions will be discouraged. Of course we must always communicate clearly the limits of intentions and guarantees, lest we create a false sense of security that can lead to severe consequences.

One of the main reasons for the growth of Internet’s re-decentralization movement (Diaspora, Bitcoin, etc.) was not only to achieve more privacy and independence, but also to build architectures that better mirror the way we want society to work in the real world (not client/service aka. master/slave). At the same time, the point of view that “technology is neutral” is getting less prevalent, being more and more replaced by an assumption that “technology has built-in values.” From this perspective, privacy tech is valuable not only as a technical defensive mechanism, but also to make a point, to convey an intention.

Importantly, Indy’s technology also enables the transformation of privacy incentives. Companies that once stored PII can now store an opaque identifier for a customer, and contact the customer’s agent to learn more–then throw away the data after they use it. This has the potential to eliminate many centralized data troves as hacking targets, and it empowers people instead of impersonal and conflicted corporate guardians. Indy also provides meaningful advances in the world’s answers to privacy regimes like GDPR. We believe that in the future, social, software, and legal constructs will evolve to take advantage of the privacy features offered by Hyperledger Indy, and that this will lead to ever more creative types of business models and digital interactions not possible before.

Guest post: Daniel Hardman, Evernym

During our recent webinar on decentralized identity, we accumulated a large backlog of questions. We thought it might be nice to cluster them by topic, and see if we could provide follow-up answers.

Q. How are decentralized identity, DIDs, and similar technologies compliant with (or not compliant with) GDPR, HIPAA and similar regulations?

Done right, decentralized identity can solve many gnarly problems. However, it’s not always done right. The decentralization is an opportunity, not a guarantee. For example, if you put personal data on the blockchain, you have a problem with GDPR’s right to be forgotten–but if you put personal data on a personal microledger, and not in a public place, you have no problem. See http://bit.ly/2taHIR8 for more details.

Q. I do not understand ‘permissioned public’ or ‘permissionless private’. Can you give examples? And why permissioned instead of permissionless?

Permissioned vs. Unpermissioned describes who can operate the network. Bitcoin is unpermissioned because anybody can download the software and run it, without asking permission first. Sovrin and Indy are permissioned, because although anybody can download and run the software, the network won’t accept your node’s vote about consensus on transactions unless/until your node receives permission to join the official validator pool.

Note that this Permissioned/Unpermissioned distinction DOES NOT affect who can use the network to do transactions. That’s a whole different question, addressed by the Public/Private distinction. A public network can be used by the general public; a private one requires special access. Permissioned/Unpermissioned just refers to who can operate the network.

A non-blockchain example of a network that is public but permissioned is ATMs. Anybody in the world can walk up to an ATM and use it, without special access. Thus it is public. But it is not the case that anybody in the world can operate an ATM. You might buy an old ATM second-hand, power it up, and turn it on–but unless banks agree to honor the transactions it does, it’s not going to work. A private permissionless network is one where only a few people can use the system, but anybody in the world can operate the node (or nodes can be configured and participate without any centralized help). An example of this would be a large conglomerate deciding to run a private instance of Ethereum for the benefit of all its subsidiaries. The conglomerate might announce that any division or department can set up a node, but say that only transactions submitted from IP addresses in its corporate intranet IP address range will be honored. Private permissionless is a little bit odd, and often permissions creep into them gradually.

Permissioned networks are helpful when you are worried about regulation (permissionless means there are few levers to control the behavior of the network providers). Permissioned are also capable of greater speed and scale than permissionless (broad generalization). Permissionless systems are naturally censorship-resistant.

Q. What is the user experience like in this brave new world of decentralized identity? How can I use decentralized identity (eID, etc) to get real work done? How do I keep track of all the keys and identity fragments that would be created in such a world?

Here’s a recorded demo that you might find interesting. It shows two sides of a decentralized identity ecosystem–a company, and a private person. The company is using a web application; the private person is using a mobile app. The person is trying to accomplish goals like buying an airplane ticket, proving things with credentials, and so forth. The web application is clunky; the user experience focus here is on the mobile app used by the private person. This demo assumes Sovrin (Indy) is the underlying plumbing. https://vimeo.com/262596133

Q. Most talk about identity centers on human beings. How do organizations and IoT things fit into the identity ecosystem?

Many decentralized identity approaches (including Sovrin and Indy, where I come from) explicitly welcome IoT things and organizations into the ecosystem. There are discussions underway on several fronts about using Sovrin for various IoT use cases, such as proving provenance of devices, securing device communication, and so forth. Organizational use cases are even more mature, with many companies and governmental organizations deploying. One public and advanced example is the Verifiable Organizations Network sponsored by the government of British Columbia in Canada.

The Sovrin Trust Framework (the constitution that Sovrin uses to run an instance of Indy) discusses the relationships of all these types of entities in section 3.2.

Q. Can a decentralized identity that is based on an immutable blockchain be deleted?

(This may relate to the question about GDPR compliance; see above for more on that.)

It depends on what you mean by “deleted”, and what you mean by “based on blockchain.” If an identity owner writes key personal info to an immutable ledger, then deleting such info will be a problem. Indy solves this problem by using the public ledger only for information about entities that don’t have a right to privacy (such as organizations or IoT devices), and requiring private individuals to store their info in a private file called a microledger. This microledger has some nice ledger characteristics–it is tamper-resistant and append-only–but the individual can always delete the file to remove all evidence of themselves.

Q. This is all utopian. Why should businesses give away their data and cooperate in this fashion? Will it take forever for the world to adopt decentralized digital identity? What about vulnerable populations who don’t own a lot of tech?

One incentive that institutions have to adopt this technology is regulation. GDPR, HIPAA, ePrivacy, and other legal requirements are forcing companies to adopt some sort of game-changing identity solution, because traditional approaches are simply too expensive or too hostile to the privacy and user-control standards that governments are demanding.

Another incentive is cybersecurity. If you were the CISO of a large company with many customers, would you feel more secure using traditional identity, where you have a large trove of information about customers that represents a juicy hacking target (including for malicious insiders)–or would you prefer to leave sensitive data in the hands of customers, with the option of looking it up from them whenever you needed it? Leaving it with customers shifts legal burdens in a huge way…

A third incentive is the possibility of eliminating middlemen. Every company would prefer to have a rich, direct interaction with its customers. Today, however, most companies are forced to have a relationship that’s mediated or brokered by some third party. They buy demographic data from data brokers; they contract with ad networks who profile and qualify people to see advertisements; they pay credit reporting agencies to identity proof customers by asking the customers when they last bought a home. All of these relationships cost businesses money and diminish the richness and power they’d like. What they’d prefer, instead, is to reach out to customers directly, knowing they can trust what customers tell them, and to have unfettered interactions with very high trust and a wonderful experience for customers.

These changes are expensive, but their benefits are so attractive that many large organizations are actively exploring the possibilities. This includes multinational banks, the travel industry, the healthcare industry, national governments, universities, and so forth.

Regarding vulnerable populations, the UN and numerous NGOs that work with vulnerable populations are striving to make this technology free and accessible to refugees, children, and those who are displaced or who live away from the internet. The Sovrin Foundation has an Identity for All committee that has interesting stories to tell…

Q. How does Indy compare to Showcard, Civic, uPort, and similar offerings? Is there any effort at compatibility or cooperation or standards?

There are efforts to cooperate. Some of them are taking place in the open, at the W3C, the DIF, and Hyperledger. Most of these efforts are midway through their lifecycle–not brand new, but not frozen into a standard yet. I am feeling very hopeful that these efforts will bear substantial fruit. You are welcome to attend community meetings at Hyperledger; see the community calendar.

I tried to take a platform-neutral stance on decentralized identity in my webinar. I can’t be perfectly objective, though, since I am a practitioner in the space. So please filter my comparison of these technologies through that lens.

All of these technologies are similar in the sense that they involved identity and blockchain. However, they use blockchain differently. They have different beliefs about what belongs on the blockchain, which blockchain to use, how to pay for the blockchain, who should control the ecosystem (if anybody), how to achieve privacy, how much privacy to aim for, and so forth. These differences manifest in different business models, different costs, different assumptions about the basis for trust, and so forth. I respect their people as bright, informed thinkers. I hope they view me as a collegial competitor. 🙂

It’s worth noting that Indy is not a product; it is an Apache 2-licensed codebase that anybody can use for free. Sovrin (an instance of Indy running with a specific constitution) is closer to being a direct analog to these commercial offerings than Indy is. Sovrin is also free.

FWIW, I believe that only Sovrin has a compelling, mature story about personal privacy, and about GDPR compliance. See http://bit.ly/2taHIR8 for more details.

Q. Isn’t there a better onboarding story than “scan your driver’s license and we’ll have our AI check it for fraud–then magically you get a digital identity”? Can we help people develop decentralized identities from birth?

Yes! Sovrin believes that digital credentials should be issued directly, and there are several initiatives underway that demonstrate exciting progress. For example 3 states in the United States are exploring the issuance of digital birth certificates. There is also effort underway among NGOs working with the United Nations to onboard vulnerable persons with a decentralized, self-sovereign, digital identity.

Q. Indy maturity — when will Android support be available, is Fabric further along, can we build something with this today?

The first network built on Indy launched publicly on July 31, 2017, running version 1.0 of Indy. Its SDK released in August of 2017. The demo mentioned above runs against software that’s now about a year old. Parts of the system are moderately mature.

That said, it is true that Indy (and really almost everything in the blockchain space, except for the core Bitcoin and Ethereum ledgers) is a very young technology, and it continues to evolve rapidly. Indy is just now finishing up the due diligence to graduate from Hyperledger incubator status. iOS support for Indy has existed for about 9 months, and Android support comes online in the next month or so. Standards efforts are forcing some evolution. If you’re a programmer, the SDK for this environment supports some common programming languages (python, java, C#, Rust, Go, Node.js) but not every language you might want. In addition, the Indy ledger, despite running as Sovrin for a year, still lacks some experience doing battle with hackers and spammers. So this is a good question; only a specific evaluation of your use cases will tell you whether it’s a good foundation for a business solution today.

Q. What consensus algorithm does Indy use?

Indy uses a modified version of RBFT called Plenum.

Missed the live webinar? Watch the on-demand replay of Decentralized Identity, Distilled today.