In a recent Hyperledger blog post, Daniel Hardman talks about Hyperledger Indy and its ‘Privacy by Design’ approach to address decentralized identity management. Unlike many systems that add privacy to their product or service after the fact, Hyperledger Indy has been built using a privacy first approach. As the world shifts to more regulation, including GDPR and ePrivacy requirements, Indy can minimize the amount of details a user shares when having their data validated by a third-party system.
Centralized identity providers, such as social media sites and consumer email services, provide convenience to users by offering the ability to sign into other online services using the same identity. However, this approach has recently received a lot of scrutiny as a result of privacy concerns and security breaches. Business Insider recently published a report citing a Facebook breach enabled attackers to use compromised Facebook credentials to access other services like Tinder, Spotify and Airbnb.
To avoid depending upon centralized identity providers, Hyperledger Indy, an open source blockchain project, is being built to address the current issues that exist in centralized identity providers including:
- A lack of transparency in how data is being used.
- Preventing the ‘over-sharing’ of data by providing only the minimal data attributes to a service provider.
- A single point of breach may have cascading consequences. If a user’s credentials have been used to sign up for other online services, those services can also be accessed using these credentials.
Avoiding data leakage is a key scenario that Hyperledger is trying to address. Hardman explains how they are able to do this:
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.
As an alternative solution to centralized identity providers, and relying upon them to guard your data sufficiently, Indy uses Decentralized Identities (DIDs). DIDs are under the control of the user that owns it and is independent from a centralized provider or authority. By using DIDs, Self-Sovereign Identity (SSI) solutions can be developed so that a person or business can store their identity and provide relevant data to service providers who can validate it using claims at the time of using the service.
DIDs are pairwise unique and pseudonymous by default to prevent correlation. Phillip J. Windley, chair of Sovrin Foundation, explains why this is important:
Indy is all about giving identity owners independent control of their personal data and relationships. Indy is built so that the owner of the identity is structurally part of transactions made about that identity. Pairwise identifiers not only prevent correlation, but they stop third parties from transacting without the identity owner taking part since the identity owner is the only place pairwise identifiers can be correlated.
While DIDs seems like a step in the right direction for end-user privacy, there are ways in which organizations may try to defeat the protection that Indy is providing. Hardman explains:
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".
Hardman feels that expressing these intentions in code and architecture does have value by itself and is optimistic about its effectiveness moving forward:
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.
Hyperledger does provide incentives for transforming privacy. Currently, storing Personal Identifiable Information (PII) creates risk for both consumers and corporations. However, by storing an opaque identifier for a customer and then making requests to a customer’s agent to obtain more information on-demand and discard after its use is a step in the right direction for consumers and de-risks broadscale data breaches.
