Decentralized Identity: Key Concepts Explained
Upcoming advancements in digital identity technologies build on the Sudo concept and include identity decentralization. Decentralized identities give users back control over their personal data, give these identities the verifiable assurance of blockchain technologies, and enable users to make assertions about their data (e.g., I’m over 21) without revealing the actual data itself (e.g., birthdate: 1 Jan 1970).
Decentralized identity puts users back in control of their identity
You’re probably aware, centralized and federated are the main identity models used on the Internet, but neither has provided an identity service that is both private and easy-to-use. A new type of model, called a decentralized identity model (also frequently referred to as a self-sovereign identity model), is an opportunity to move beyond current limitations. Based on distributed ledger technology (e.g., blockchain), a decentralized identity returns the control and administration of the identity back to the user rather than leaving it under the control of another party (web service or site).
Here are the key points to know about decentralized identities:
- Identity Ownership: Users create and hold identities (in their digital wallets) rather than having their data in the control of any website or application.
- Data Ownership: Identities create and control personal data stores with access delegated only to the services that need it.
- Secure Cryptography: Identities are created with a unique public and private keypair that is used for encryption, signing, and making relationships with other parties.
- Peer-To-Peer Relationships: Identities can be used to form unique cryptographic relationships with other entities (e.g. other users, web sites). This provides the foundations for end-to-end encrypted communication, authentication and so on.
- Edge and Cloud Agents: Software components are available to help manage the decentralized identities, including setting up relationships and handling communications.
- Verifiable Credentials: Identities can make assertions which are cryptographically verifiable by the receiving party.
- Zero Knowledge Proofs (ZKP): As part of the verifiable credential system, ZKPs enable identities to make assertions about data without revealing the data itself.
Now let’s dive deeper into each concept.
Under a decentralized model, users create their own identity using their local identity creation tools (such as provided by a digital wallet app). The new identity resides in the user’s local wallet, which remains securely on the user’s own devices. This model enables the user to take their identity with them wherever they go and transfer (or replicate) it to any of their own devices. Since the identity remains within the user’s control, it can’t be deleted (purposefully or inadvertently) by a remote application or compromised if a remote website gets breached.
In addition to ownership over the identity itself, decentralized identity provides complete ownership over user data via personal datastores, called identity hubs. Each identity can have one or more identity hub that can store data for one or more services. The key difference between storing data with a specific service via their platform and storing it in an identity hub is that the user retains full ownership of the data, including who can access it. If the user decides to discontinue using the service, or move to a different one, they retain full control over their data.
Each identity will contain a decentralized identifier (DID) and a unique private/public encryption pair. DIDs are created as Uniform Resource Identifiers (URIs) and reference individual identities similarly to how URLs form references to web pages.
The format of a DID starts with a scheme that defines the URI as a DID. The DID Method is a service location where the DID is hosted and resolved, such as the name sov, which resolves at the Sovrin Network. Other users can obtain public information and verify assertions via the DID Method. The DID Specific Method String is a unique value, within the DID Method, for a given user’s identity. What makes DIDs useful is that they are self-certifying identifiers (users can verify that the link is real) and they can return a companion DID Document (also called a DID Doc) that contains additional information, such as their cloud agent’s address, encryption keys, digital signatures, pointers to additional information, etc.
Users may also publish their identity publicly by writing their DID to a distributed ledger or blockchain. The distributed ledger serves as a trusted, decentralized public key infrastructure. By leveraging the ledger, users can create connections that can be verified by any other user or entity by querying the ledger.
One of the clear advantages of decentralized models over current models is that decentralized identity users negotiate peer relationships with the users or applications with which they connect. In traditional identity models, a username and password (or its hash) is often sent to a remote application when authenticating a user. Conversely, in decentralized identity models, the identity owner and the remote application securely exchange unique DIDs when creating a new peer relationship. These relationship specific DIDs are known as pairwise DIDs and are kept only with the negotiating parties (i.e., are never posted to a public ledger) for use during their encrypted operations. Since the pairwise DIDs are privately negotiated only between the two parties, no external public key server, host messaging server, etc. has access to the keys or plaintext messages and strong end-to-end encryption is achieved.
With peer relationships, either party can choose to terminate the relationship at any time and doing so does not delete the identity. Conversely, under centralized and federated models, a user’s identities exist at the behest of the owning applications and can even be deleted by the owning application. In fact, if every centralized or federated application decided to delete a user’s identity, then that user would effectively cease to exist, at least online.
One significant benefit to users is that pairwise DIDs enable them to identify remote users and establish fully end-to-end encrypted communications with them by using the capabilities of their decentralized identity-enabled apps, while keeping the private encryption keys safely within their own devices. The benefit of this standardized encrypted communications can be understood by examining the current encrypted messaging space. Applications such as WhatsApp, Signal, Wire and MySudo all have end to end encrypted communications. However, they only work within their own system (i.e., Signal app to Signal app), and encrypted communications are not currently possible between separately hosted applications (i.e., Signal app to MySudo app). Communications using DIDs and DID-based communication protocols, can bridge end-to-end encrypted communications between separate walled gardens.
Edge and Cloud Agents
Users can install applications and subscribe to digital identity services for a wide range of purposes. Digital identity apps that provide local functionality and services (e.g., decentralized identity wallet) provide what is called an edge agent. Digital identity owners can also employ a cloud agent to help them with cloud-based activities. For example, a cloud agent can receive messages sent from remote peers and store them until an identity owner’s edge agent (e.g., device, app, etc.) connects to the cloud and is ready to receive them.
Both edge and cloud agents abstract the complexity of strong cryptographic services and simplify decentralized identity operations, so that users can invoke very complex operations with a simple button press, such as: ‘Create digital wallet’ or ‘Create identity’. This simplification matches the complexity tolerance threshold of the average internet user and results in apps that users will actually use.
Using edge agents, users become better equipped to easily and unobtrusively manage their identities, public keys, enter into end-to-end encrypted communications with other parties, etc. Similarly, cloud agents enable users to carry out cloud-based operations (e.g., receiving messages) without needing their personal devices to be continuously online.
Verifiable credentials are a standardized method for issuing and presenting claims about a person’s identity (e.g., driver’s license, university qualifications, passport, gym membership, etc.). An owner of a verifiable credential can create assertions about those claims (e.g., ‘I graduated’, ‘I’m over 21’, ‘I paid my fees’, etc.) and present those assertions to other parties who can then verify them using decentralized identity cryptographic methods.
Using this process, users can convey trusted and validated information to requesting parties who can validate the information’s authenticity. The potential use cases for verifiable credentials are virtually unlimited and can support high value credentials, such as government IDs, digital university diplomas, etc. Additionally, using verifiable credentials can simplify everyday authentication scenarios like website logins, in app credits, social media post authorship, etc.
Zero Knowledge Proofs
Another major cryptographic element used by decentralized identities requesting and validating verifiable credential assertions is known as a zero knowledge proof (ZKP). The purpose of ZKPs is to enable two parties to make and validate assertions about a data item without having to disclose the data item itself.
Under centralized or federated architectures, a user can instruct their service operator to provide assertions to other parties. One example is when users provide their birthdate to a host operator who may unlock select information for permitted users. Some of the downsides to this method include users providing a false birthdate or attacks that disclose personal data to hackers. Both site operators and users are left simply hoping that information remains accurate and secure.
Using ZKPs, users (possessing issued verifiable credentials) may assert relevant facts about themselves without having to divulge their actual personal data. For example, using ZKPs a user may receive a national identity credential from a governmental agency, which would contain their birthdate. To participate in some services (e.g., social media accounts), users must prove that they are above a certain age (e.g., age 13 for Facebook). The user could then present the service with verifiable proof that they are above a certain age using the credential from the government agency. The service knows that the user is above a certain age and that this information is provided by a trusted credential, but never knows the specific birthdate of the user. This helps to protect the privacy of the user and protects against the leak of personally identifying information since the birthdate was never provided.