Decentralized Identity
An Introduction to Sending.Network’s Decentralized Identifier System
In everyday life, identity is a key concept used in many human social and economic interactions. A verifiable identity is often required to access critical services such as banking, voting, medical care, etc. An identifier is a piece of information about a particular identity, such as name, date of birth, home address, or email address, and it is typically issued by authorized entities like governments or organizations. As the Internet becomes ubiquitous, digital identities are needed to access many online applications and services; so, more and more people now have individual identities for each of their Google, Twitter, Facebook, and Netflix accounts to consume the digital content these online platforms provide.
Both traditional and digital identities are issued and controlled by centralized entities. Any creation or change of such an identity must go through that central entity, which has complete control over it. For example, you need the government's approval to change your name and Google’s approval to create a new Gmail account – both these entities can revoke the use of that identity. Another problem with centralized identity systems is that they are insecure, fragmented, and exclusionary. Centralized databases are major targets for hackers. Every now and again, we hear of thousands or even millions of user records stolen because a centralized database is hacked.
Besides security issues, a centralized identity system is owned by the controlling entity rather than the actual owners of the identification information. This is unfair to the identity owners and also brings privacy issues. To fix these problems, a new concept called Decentralized Identity (DID) is introduced, which is built on top of the blockchain and Web3 technologies. DID enables users to own and control their identities and provides a way for digital identities to be used across multiple platforms without sacrificing user experience and security.
In this article, we will describe how Sending.Network’s DID system is designed and implemented.
Brief Introduction to Sending.Network
Sending.Network (SDN) is a decentralized communication network, providing, among other services, the ability for users to participate in peer-to-peer chat without the use of centralized servers. Web3 application developers can add chat and other communication facilities into their apps using Sending.Network’s SDK and APIs. The advantage for the user when using apps that use Sending.Network for their messaging is the ability to have an integrated view of their social graphs, personal data, messaging contacts and history across all these apps.
Since SDN system is built on top of crypto wallet addresses and users commonly have multiple wallet addresses for different Web3 apps, it is necessary to ensure that users can be associated with the same SDN account when logging in with separate wallet addresses. Otherwise, users may lose all social connections created with that account by switching to a new wallet address created for another app. This kind of account system does not have the essential ability to host a Web3-based social network. Therefore, we have introduced a DID-based solution to identify the user, verify that identity when it sends a message, and support multiple wallet addresses linked to the same identity.
Why do we need DIDs?
People have digital identities in an era where the digital wave has reached every aspect of our lives. Such identities may be IP addresses, PayPal accounts, Twitter accounts, etc., issued by the platform operator or service provider to identify the user within a network or an application. People use these identities to access relevant services.
However, these identities are not owned by the users of the networks or applications. Instead, they are rented from the owners of these networks and applications. As a result, it's easy to be exposed to the risk of digital identities being manipulated, hacked, revoked, or lost altogether. Often, people trust these platforms to refrain from revoking their use or revealing their identity willy-nilly. But such trust has neither a technical guarantee nor an empirical basis. The carrier can ban your IP address, the government can seize your account, and the platform can block your social accounts.
Numerous examples warn us that relying on a separate third-party entity to safeguard people's digital rights is risky. There is an urgent need for a new technology solution that allows people to independently prove whom they are in the digital world, untied to third parties. DID technology was introduced for this purpose.
What is DID?
DID is a new identity identifier system that supports a verified decentralized digital identity. It could become the identity certificate used by the decentralized society of the future. By combining digital signatures, blockchain, decentralized file systems, and peer-to-peer networks, decentralized identity enables identity creation and verification without centralized third-party involvement. The user's identity is fully controlled by the owner and not locked into a single ecosystem or entity. Even if an entity stops serving for some reason, it does not affect the DID owner’s ability to interact with other players in the ecosystem.
Standards for DIDs
The World Wide Web Consortium (W3C), one of the most influential international Internet technical standards bodies, has created a widely accepted standard for DIDs. W3C’s DID specification is designed to enable individuals and organizations to generate identity systems that can interoperate across different networks and platforms using means they trust. Its basic architecture is shown in Figure 1, adapted from the W3C standard, which identifies the key entities that interact to support a DID.
As shown in Figure 1, a DID describes a DID Subject (which can be a person, organization, or thing) and is recorded in a Data Registry, which can be a blockchain or a decentralized database. The DID itself points to a DID Document created and updated by a DID Controller (the same or another person, organization, or thing), and which contains metadata about the subject such as the pubic key, the authorizations granted by the subject, and other identity-related information. The W3C standard does not specify a specific implementation for the individual entities shown in the figure. Many Web3 applications are designing digital identities using the DID syntax to fit their computing and networking infrastructure. For example, Sending.Network (SDN) defines a DID for its peer-to-peer messaging service that allows users to be identified by their SDN DID, which allows apps that integrate SDN as their messaging solution to offer their users the benefits of the DID. How this is achieved is the subject of the rest of this paper. A DID specifies the following data.
DID Identifier
The DID Identifier (hereinafter referred to as identifier) is a type of Uniform Resource Identifier (URI). It is an immutable string that globally and uniquely identifies a user in a specific domain. It consists of three parts.
The first part is fixed as did, indicating that this is a decentralized identifier.
The second part is the DID method name, indicating the domain or namespace which has created this identity, and which set of methods can be used to create and manipulate (read, update, etc.) the metadata associated with that identity.
The third part is the identifier specific to the DID method, unique throughout the DID method namespace. It can be any string that represents the address of the identity corresponding to this DID.
Take an SDN identifier, shown in Figure 2, as an example: Here, the blue part did indicates that the string is a DID. The red part sdn is the DID Method name for DIDs of this type. Our example shows that the identity is created in the domain SDN. The green part is the Method-Specific Identifier, which indicates the address of the identity in the domain.
The DID resolves to a DID Document. As shown in Figure 1, this requires the service of a DID Resolver, specific to that domain (or “method”). Thus, in our case, SDN would configure nodes in its peer-to-peer network which serves as DID resolvers.
DID Documentation
A DID is just an identifier – it simply represents an identity and does not contain information about the identity, such as who owns it. Instead, a DID document (hereinafter referred to as a document) associated with the identifier is a JSON string that provides the metadata about that identity.
In general, one entity (the DID Controller – see Figure 1) can create a DID to identify another entity (the DID Subject). SDN creates DIDs for users – the DID Subjects – based on their wallet address(es), which makes SDN the Controller. Hereafter, we shall use more informal terms such as holder, owner, or subject instead of DID Subject.
To prove that the user is the holder/owner of the DID, the document should include at least the following:
DID Identifier: Identifies the unique DID of the holder/owner for which the document provides metadata.
Validation methods: a set of parameters (e.g., the holder’s public key) to validate the relationship between the DID and its holder.
Timestamp: the creation time and update time of the document.
Besides these necessary parameters, designers can add more information about the subject identified by the DID, such as age, name, preferences, etc., if available and subject to privacy requirements.
DID Method
Usually, the size of a document is much larger than the size of the identifier, so it is typical to store only the identifier and outsource the document to a trusted third party, such as decentralized storage like blockchains. Thus, users who need to interact with the subject identified by the DID require a mechanism to retrieve the document and check its integrity upon receiving it.
The DID Method is a set of operations defined for that domain to create, resolve, verify, update, and deactivate a DID by creating and manipulating the corresponding document. It specifies a set of cryptography methods used to ascertain the DID's possession, the documents' completeness, and the relationship between identifiers and documents.
Before making any changes to a DID, the document is checked to verify that the caller has the appropriate privileges.
SDN DID
Background
The use of DID in Web3 applications is in its infancy, and multiple solutions exist, but none of these provide a common identity that works across various apps. Furthermore, many app developers tie DIDs to their user accounts, making the identities non-interoperable to protect their own ecosystem's irreplaceability. Therefore, users are forced to use different DIDs on different platforms, which defeats the original purpose of the DID design – a single identity that works across multiple platforms, applications, and infrastructures.
We have designed a decentralized P2P chat system for SDN that can break through different ecosystem barriers. Thus, we have developed a DID system that allows users to define and control their digital identities across any platform that has integrated SDN as their underlying communications infrastructure. Our design of the DID system is based on the following objectives.
Achieve many-to-many relationships between Wallets and DIDs: Users can map multiple wallets to a single DID and a single wallet to multiple DIDs.
Multi-chain support: support for Ethereum and EVM-compatible blockchains.
Efficient proof mechanism: help message recipients verify the sender's identity quickly.
This article will describe how we achieve these goals and briefly describe our implementation of an SDN DID.
The Mapping Between DID and Wallet Address
Currently, mainstream decentralized verifiable wallets contain a pair of keys, where the public key is exchanged and the wallet’s owner retains the private key. The user's wallet ownership is proven by verifying messages signed with the wallet’s private key.
We enable users to map a wallet to a DID within the SDN by writing the wallet address in the document. When the user first interacts with a Web3 app that has integrated SDN into its messaging infrastructure, SDN uses the app’s wallet address (whether a built-in wallet or a third-party wallet) to generate a DID, and create the corresponding DID document. This wallet used to create the DID is called the master wallet and is stored in the document.
Using the DID method we designed, a user can prove the ownership of their DID by signing the document with their wallet’s private key. Verifying this signature in subsequent interactions shows that the user possesses the private key of the wallet address in their document, the same private key they use to log in to their wallet.
If the user subsequently uses that wallet with another app – as would be the case when the wallet is a third-party product such as MetaMask – then SDN searches its internal, decentralized databases to find a DID associated with this wallet. If such a DID is found, SDN knows it is the same user and can provide an integrated view of the user’s interactions across these two apps.
If the user chooses a different wallet to interact with another app, SDN will not find a DID associated with that wallet address. Therefore, as described in previous paragraphs, it will create a new DID with that wallet address. The user then has two different DIDs, and it is not possible for SDN to integrate the user’s interactions across the two.
However, SDN offers the user a way to integrate multiple wallet addresses into a single DID, i.e., record multiple wallet addresses in the same document.
Specifically, SDN DIDs are designed with the concept of a master wallet and sub-wallet. The wallet address used to create the DID is called the master wallet, while others subsequently associated with the DID are called sub-wallets.
Only the user who is the DID owner and controls the master wallet can add new sub-wallets to the DID. This assumes that the user is (or has been) educated about DIDs and wallets and the benefits of their integration via the SDN infrastructure.
In addition, you can bind the same wallet to different DIDs simultaneously. Since the documents are independent, SDN will prompt the user to log in to a wallet with one of the identities.
Figure 3 illustrates an example of the above mechanism in three steps:
A user first creates DID 1 and maps wallet A to it, as shown in the upper portion of Figure 3. Then, the user can interact with the document associated with DID 1 using wallet A.
Now, wallet A is the master wallet of DID 1, so the user has the right to add (“bind”) wallet B as a sub-wallet, as shown on the right-hand side of Figure 3. After that, the user can also interact as DID 1 with wallet B.
The user could also create DID 2 and maps wallet B, as shown in the bottom portion of Figure 3. Now, wallet B is both the master wallet of DID 2 and a sub-wallet of DID 1. When interacting with apps using wallet B, the system will prompt the user to choose DID 1 or DID 2.
The master wallet and the sub-wallets can be from different blockchains, enabling cross-chain logins so long as the apps using these wallets employ the underlying SDN network for P2P messaging.
SDN DID Document Structure
As mentioned earlier, we have modified the document structure to support recording and verifying multiple wallet addresses to achieve our design goal. An example of a document is shown as code example 1, which includes the document ID, digital signature, verification method, etc. The fields id, verificationMethod, controllerSignature, and keySignature are the primary information needed to map wallet addresses and DIDs.
Code Example 1: An example DID Document
Document ID
In code example 1, the field id, with the value of did:sdn:0db0…0573, is the DID Identifier, where 0db0…0573 is the address of the master wallet. When creating a document, this field will be initialized with the wallet address specified by the document Controller, which is, in our case, the owner of the DID. Then, the DID owner needs to sign the document with the private key corresponding to the wallet address. The SDN network verifies the signature before storing the document, which prevents other users from forging the document. The signature can also be used by other users to verify that the DID belongs to the identified user using the public key provided therein.
Users can use the id field to resolve a unique DID document. After obtaining the document, the signature verification algorithm is used to recover the wallet address corresponding to the signature from the controllerSignature (see below) to determine whether the document has been tampered with.
Privilege Addresses
The verification methods in the document contain two types of wallet addresses, which are relative to the privilege of who can use the DID to send messages.
Controller Address: This field comprises the wallet address and the privilege tag
#controller. It associates the wallet address with the privileges of the controller, which includes permission to add a public key to the document. Only the DID owner can add or remove the Controller Address.The example document contains two Controller Addresses:
0db0…0573 and d514…79ff, whose ids are:did:sdn:0db0…0573#controlleranddid:sdn:0db0…0573#controller-d51414ee0erespectively.Public Key: This field is the public key added by the Controller Address, composed of the key value and the suffix starting with #key. The Public Key is used to verify the signature of the message sent by the user; that is, owners of the Public Key have the right to send messages with the DID. All Controller Addresses in the document can add or remove the Public Key.
The example document contains a Public Key, that is,
FHVG…PCQG, whose id isdid:sdn:0db0…#key-FHVG9LamZ3.
Privilege Signatures
Corresponding to the Privilege Addresses, these signatures are used to verify permissions when updating Privilege Addresses.
controllerSignature: To update a document, the DID owner signs data fields (except Public Key) and generates thecontrollerSignature. It’s used to verify that the owner adds the content modified in the document. The wallet address recovered from the signature must match the DID owner’s address.The
controllerSignaturevalue in the example document is the signature of the following content after being serialized.
keySignature: the signature of the data fields (except the Controller Address). It is used to verify that the Controller adds the new Public Key in the document. Any Controller can sign it with the EcdsaSecp256k1RecoveryMethod2020 signing algorithm. After the user has recovered the signer's address from the signature, it is necessary to determine whether this address is in the Controller Address list.The
keySignaturevalue in the example DID document is the signature after serialization of the following content.
Message Verification
As a type of digital identity, DID is used to verify the identity of communicating parties in the SDN, and Figure 4 illustrates the process. A random key pair is generated when the client is started and the public key will be updated in the DID document after the user signs in with the master wallet or sub-wallet.
After logging in, the master wallet address of the DID will be used as the user id. Then, the user signs a message with the private key generated on the client and sends it to the receiver.
After receiving the message, the receiver obtains the document from the edge node corresponding to the sender’s user id based on the user’s master wallet address. Then, the receiver verifies the document’s integrity by checking the controllerSignature and keySignature. If both the document and the signature are legal, the receiver can determine the sender’s identity and accepts the message.
CRUD Operations
The SDN DID Method provides users with four interfaces to support DID's Create, Read, Update and Delete (CRUD) operations.
Create (Register)
To create an SDN DID, the user must have a cryptographic wallet address, e.g., Ethereum address: 0dB058993Cf429B9bf3b84904e597b098EE60573. The user must sign the data with his private key to prove they are the owner of the wallet address. After completing the registration, the SDN will generate a document, as shown below.
After the user creates a new document, a new set of data will be added to the verificationMethod field, and the field blockchainAccountId is the user’s wallet address. (Note that in our simplified case, the user who creates the DID is both the Subject as well as Controller, ie.e, owner of the corresponding document.)
Add/Delete Wallet Address
The DID owner can add a new Controller Address to the document. As shown in the code snippet below, a new Controller Address is added to the document with the address d514…79fF.
The “add wallet address” operation will add a new verification method to the verificationMethod array, where the field blockchainAccountId is the new controller address. After that, the new controller address, d514…79fF, can add a new Public Key to the document.
Similarly, the owner of the DID can also delete other ControllerAddress from the document. The deleted Controller Address(es) can no longer modify the document.
Add Public Key
After creating the DID, the Controller Address can add the public key to the document, where the public key is used to verify whether the signature is valid upon receiving the signed message, that is, whether the message was sent by the user and not forged by another user.
Get Documents Based on Wallet Address
When using the SDN DID method, users can add a wallet address to multiple documents, as well as add multiple wallet addresses to the same DID document. Getting the documents corresponding to a wallet address consists of the following steps:
Get the list of DIDs bound to the wallet address. The current address is not associated with any SDN DID if the list is empty.
If the list is not empty, prompt the user to select one of the DIDs.
Use the DID to query the document from the edge node.
The Advantages of SDN DID
Compared to other DID implementations, SDN DID fully considers the difficulties faced by Web3 applications, to make it the most appropriate DID system for decentralized P2P chat.
Support Multi-Wallet Login
SDN DID allows users to set their wallets from different blockchains as the master wallet and sub-wallets separately, all of which can be used to interact using the same DID. Compared with other DID implementations in which a wallet can only map to a single identifier, SDN DID can maintain the stability of user identity, so they do not need to switch between multiple wallets repeatedly.
Storage
SDN has built a distributed storage system to store DID information, using libp2p to distribute and retrieve data. Each client will be randomly assigned 3 edge nodes to store the DID document, ensuring that the DID document can still be found when some nodes are down, which improves the reliability and availability of the SDN DID system. A node update mechanism reassigns a new edge node to the client in case some nodes are out of service. This avoids the problem of a single point of failure, which is common in centralized storage. Moreover, in the future, users can save their documents to a public blockchain.
Security and Privacy
The DID document only stores the wallet address and the public key used to verify the message signature. The user’s private key remains on the local client device. Therefore, there is no risk of private key leakage. At the same time, users are required to sign any document creation and modification actions. These signatures verify the document's integrity, preventing any malicious tampering. Also, to avoid the risk of privacy leakage, the DID document shouldn’t store any personal information related to the user, unless allowed by the user and with the understanding of any risks involved.
Summary
By adding an independent DID system to SDN, users can have a unique digital identity on that works across all their wallets. Users can bind and log into the same DID with wallet addresses from different chains, realizing the cross-chain capability of the SDN network and enabling users to create different identities according to different needs.
Last updated
