Part 2 of our discussion around Decentralized Identification solutions, Ethereum Name Service (ENS), and Decentralized Identifiers (DID)
In the previous article, Why ENS does not spell END for DID (part 1), we mentioned that ENS domain names are essentially also decentralized identifiers. So the question is whether there is any difference between ENS and DID?
The identifier of ENS is the domain name, namely “xxx.eth”. This identifier is readable for users, which is also the most basic goal of ENS, to make unreadable Ethereum addresses resolve to user-friendly identifiers ENS domain names through ENS.
For DID, its identifier is “did:method:xxxxxx”, for example, the DID identifier provided by Ontology is: “Did:ont:AMQoUFjwjVNNSejomUPRmGrkQDyvmujDt5”, which is a string of “did”, DID Method name “ont” and the address on the Ontology, which is unreadable to users.
However, the identifier of DID is not fixed but can be designed according to requirements. The DID Method rules give the designer the ability to define DID specifications, and the designer of the DID scheme can also design it as a readable address, such as “did:ont:iris”. This means that designers can take greater initiative in the readability of DID identifiers.
In addition to identifiers, ENS and DID are also very different in their implementation logic.
For now, ENS itself pays more attention to the associated address. For users, ENS associates the user’s Ethereum address with the domain name through the functions of resolution and reverse resolution, and realizes the binding of the domain name and the internet account. This is then realized as a single sign-on in Web3;
The information that DID pays attention to is more extensive, and it is also biased towards user personal data:
- Contains user’s on-chain data, such as multi-chain addresses, content hashes, on-chain interactions, etc.;
- Follow users’ off-chain information, in addition to internet information such as Twitter and mailboxes, they will also follow users’ actual data through third-party authoritative institutions. These sensitive data will be encrypted to generate verifiable credentials, which are saved by the user.
2. On-chain storage
For user data (on-chain and off-chain), ENS and DID have different storage methods.
ENS is recorded through the Ethereum smart contract (parser), for example, the content identifier in the IPFS network is recorded through content hash; centralized information such as Twitter, Github, and Email is recorded through text. This means that ENS-based accounts are more open and can be checked.
According to a survey conducted by DAOrayaki, nearly 70% of Sismo respondents indicated that they were unwilling to associate ENS with their private address because the account information was too easy to be queried.
But in general practice, the DID can be designed by the designer according to the needs. The usual design is for insensitive information to be stored on-chain, and sensitive information being verified through off-chain verification to generate VC and other forms for users to save in their own DID. This method better protects users’ privacy.
3. Permission control
In the management of ENS, there are two roles:
- The registrant, who is the real owner of the domain name and can appoint an administrator or resell the domain name.
- The administrator, who has only the authority to manage the domain name, such as the transfer of the administrator and the setting of the domain name.
*If a new administrator is set, the registrant can no longer set the resolver and resolution record of the domain name. These operations must be performed by the administrator.
DID has a more refined write permission control. According to the description of the W3C DID document, a DID can have multiple verification methods. These verification methods have the rights to change the DID file, authenticate DID entities, and designate agents, including creation, verification, update, and deactivation. Therefore, in terms of access control, the management role of DID appears to be more refined and specific.
The creation of ENS is based on Ethereum. As such, regardless of whether it is created or held, it is necessary to pay on-chain fees on Ethereum. According to the setting of ENS, holding an ENS domain name requires the payment of a rental fee. The fewer the number of words, the higher the rental fee. The annual rental fee for a domain name within three words is as high as $640 USD.
At the same time, ENS is also an NFT, which means that ENS can be resold in NFT markets such as Opensea. These can meet the needs of users for unbinding and monetization.
For the creation of DID, the user can choose which blockchain to be based on, and it will also incur a certain fee. Moreover, once the DID is created and bound with the user’s identity, it cannot be transferred or destroyed. Therefore, users need to be careful when creating a DID, because DID grants data and identity independent management rights, but also gives users responsibility for their identity. As such, users need to improve their identity and data usage awareness and use their data more securely.
In summary, although ENS can also be used as a decentralized identity at the application level, it is still quite different from DID in terms of the underlying implementation logic and details.
Perhaps in the future, ENS will have more refined upgrades, such as KYC and other methods to achieve interaction with off-chain data, adding verifiable credentials to meet the needs of users, including privacy. But for now, it is too early to replace DID.