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.