Author: Robert Mao, ArcBlock Founder/CEO

Illustration: Moon Cao ArcBlock UX Designer

On June 30, Sir Tim Berners-Lee overruled Google, Mozilla, etc.'s veto of DID Core becoming a W3C Recommendation, paving the way for DID Core to finally become a W3C Recommendation. This is a victory for all members and contributors of the W3C CCG (Credentials Community Group ), and even more so for users. Considering that DID was the first Self-Sovereign Identity (SSI) protocol to become a W3C Recommendation, it could even be said that this was a victory for the people.

A few days after this, July 4th coincided with the United States Independence Day, a day commemorating the declaration of independence by the United States of America on July 4, 1776. I think the DID Core becoming a W3C standard may be seen as a kind of "Declaration of Independence" of the Decentralized Identity technology, and in the long run its significance may be as far-reaching as Independence Day.

What is DID?

Let's start with a brief introduction to DID in a few words. The basis of the W3C's DID Core specification is really just the definition of a standard format for a "Decentralized Identifier".

This format looks much like the familiar and common web address starting with https://, and is divided into three parts.

• The first part is always "DID", which indicates that it is a "Decentralized Identifier".
• The second part is called "Method", the ABT in the example is the DID method defined by our ArcBlock
• The third part can be any string, and its definition, creation and interpretation are entirely defined and implemented by the method provider of the second part

For example, the user ID on Facebook is a sequential number, and the same number may appear in other systems, often representing a completely different thing. For example, my Facebook user ID is 1314596489, but that ID might represent a book at Amazon or a photo at Instagram. With the DID specification, a globally unique identifier can be clearly defined, and no matter which system the object is in and who develops the implementation there can be no more confusion.

A unique (but criticized by Google and Mozilla) design of DID Core is to allow a large number of registered methods, and the identity behind them is defined and interpreted by these different methods. This design itself embodies the spirit of decentralization, and gives DID the flexibility to be infinitely scalable and compatible with existing legacy ID systems. From a short list of Methods when we participated in early 2019, this is now a list several pages long, and the list of members and supported methods is expected to become even larger as DID Core becomes a standard.

Among the objections to the draft DID protocol from Google and Mozilla, one of the criticisms is that DID supports many methods without a strict definition of standard methods, and since there are many methods that need to be interoperable, this is another area of criticism; since methods can have multiple implementations, it means that some methods might not be as decentralized as some others, which is another reason for Google's rejection. But I think this is not a design flaw, but precisely the embodiment of decentralization. I don’t think those large and established companies can not see the value of doing so, it’s more likely they fear that such a design will make them lose their vested interests and the monopoly of user identity and data.

The W3C's DID also defines the concept of DID Document, which is a very scalable design that not only unifies DID and URI (Universal Resource Identifier), but also draws on many lessons learned from past Internet protocols. It’s easily misunderstood and confused for DID document, so I won't go into those details in this article.

What are Verifiable Credentials?

DIDs are only the most basic layer, and Verifiable Credentials, which are based on DIDs, are the key to unlocking many application scenarios.

Verifiable Credentials is a data format specification that includes a digital signature to enable verification. The concept is very simple, meaning that the data format contains some verification information that makes it efficient to verify and cannot be tampered with or corrupted. The signature and verification techniques used here have been commonly used in many Internet applications and are very mature technologies and practices. The purpose of designing the specification here is to standardize these data formats so that different systems and implementations can interoperate effectively.

The W3C CCG proposes such an abstract generic conceptual model for the design of DID-based verifiable credentials as

In this model, the roles of each part of the certificate are mainly divided into Issuer, Holder and Verifier, and each role is identified by a DID, and verifiable credentials are data that can be verified by signature algorithms.

From DIDs to verifiable credentials are not necessarily related to today's blockchain and cryptocurrencies. The design of verifiable credentials often uses hash and signature algorithms similar to those widely used in today's blockchain. In the above model, there is also a role of Verifiable Data Registry (VDR), which can be implemented by blockchain, but it is not necessary to use blockchain, it can be implemented by traditional database or even a common file according to the actual application scenario. In my article "How ArcBlock uses AWS QLDB to build a decentralized identity solution", I introduced a way to use AWS QLDB as DID implementation of VDR.

The W3C CCG document "Verifiable Claims Working Groups' Use Cases" lists a number of scenarios and examples of practical applications that can be solved using verifiable credentials. The document "Verifiable Claims Working Groups' Use Cases" by CCG lists a number of scenarios and examples of practical applications that can be solved using verifiable credentials. Many of the "enterprise blockchain application scenarios" seen in the market are in fact typical scenarios for verifiable credentials.

There are many specific scenarios where verifiable credentials can be used, so here are some random examples of applications.

• Are you over a certain age? For example, buying alcohol and tobacco or entering age-restricted places
• Are you able to drive a motor vehicle? Such as a digital driver's license
• Have you passed certain training and obtained certain qualifications? e.g. digital academic and training certificates
• Have a professional license, such as a license to practice medicine? Such as a digital license
• Is it KYC verified? Are you a qualified investor under certain laws and regulations?
• Is international travel allowed? Such as a visa, passport, vaccination card, etc.
• ...

Some people may say that all of the above examples are already implemented today and even in daily use. Yes, many of the above examples are scenarios in use today, but there are several problems, first of all basically these centralized design based authentication systems need to have perfect network connectivity and may fail in certain network environments or unexpected events; secondly these centralized designs may become important targets for hacking tools, often resulting in serious data breaches and privacy disasters; then these today's solutions are often implemented by specific vendors or government parts of various kinds, which cannot be well interconnected, and users often need numerous apps in their phones to adapt to various different applications. DID's verifiable certificate design goal is not only to complete the above applications, but also to ensure the decentralized nature and protect the privacy of users.

DID unlocks a new application development paradigm

What we see is the range of future application opportunities that DID brings and its migration to the application development paradigm. DID, decentralized applications, and the recent Web3 movement coincide. It is conceivable that DID technology will become a key technology revolution in the Web3 movement.

DID standardization of the Identifier makes interoperability between different software modules and systems easier, and more importantly, the core idea of DID is to let users, not service providers, own and control their own data completely, which is a huge shift in thinking about the past Internet era, especially Web2. In the past, the "core competitiveness" of Internet services was how much user data they had, so the key to competition between vendors and vendors is to see who controls more user data, while under the DID idea, only users own their own data, vendors are only concentrating on providing services or software, which makes the closer cooperation between software and services This makes the closer cooperation between software and services become less serious conflict of interest.

We realized the need for a decentralized identity back in 2017 when ArcBlock was created, but at that time we hadn't found the most suitable solution. In 2018 we researched various solutions in the current market and were attracted to the DID proposed by the W3C CCG and decided it was the best choice among the various decentralized identities in the market. Since the first half of 2019, we have incorporated DID technology into our core technology stack and have been working on this area since then. In 2022, we even spun off DID-related technologies to form DID Labs as part of the ecosystem, allowing for more independent and focused development of DID technology.

We were involved in the DID process at a time when standards were not being developed, and industry standards often mean a long time and a lot of discussion and compromise, and it is often difficult to have the resources and time as a startup to follow the standards development process. We have adopted a more flexible and lightweight approach to participation.

We actively participate in the standards organization's community and carefully study the documentation, minutes, and discussions generated by the community. We play more of a listening and learning role in the community than an active role in exporting ideas.

We do not wait for standards and community consensus (which generally takes quite a long time), but quickly implement and try out our own versions according to our own understanding, and after our own prototypes or even products are implemented, we improve them against what others in the community have done or the structure of the discussions. This approach allows us not to spend a lot of time on standards that have not yet been developed, and not to become entrenched in our own ways.

In terms of interoperability with other DID methods, we took a wait-and-see approach and did not spend any effort in the early stages, but we kept an eye on the community and worked on interoperability when the standard was formally formed.

With this strategy, we have implemented a series of DID-related modules around the W3C DID Core recommendations and our own innovations, forming a product system that is now complete and ready to use out of the box.

• Native DID-based Blockchain Addresses: Blockchain Addresses with DID
• DID/VC-based NFT format: NFT data format using DID and VC
• DID/VC-based Access Control Passport: DID and VC-based access control format
• DID Wallet: A wallet used by users to manage their decentralized identity and digital assets
• DID Connect: A protocol that uses DID to connect users to applications
• DID Motif: A visual rendering library for DIDs that allows users to distinguish different DIDs at a glance by the difference in pattern color
• DID Storage: A user data access protocol and decentralized data storage format managed by DIDs

We will open source and contribute to the DID community the parts of these product systems that we have created ourselves, and will also fully embrace standards and interoperability as the formal standards for DID are formed.

Challenges for the future of DID

W3C DID will be a formal W3C Recommended Standard. This is a huge victory milestone for all DID promoters, but it is also just the beginning of a long road to decentralization. What has become a W3C Recommendation is still only the most basic protocol, DID Core, and building applications based on DID requires much more than that. The future of DID technology will face many challenges, more standards and specifications for the formation of a long way to go.

The W3C CCG's DID is not the only standard for decentralized identity either, there are other competing or similar protocols that can be considered as different schools of thought competing in the same direction. Other protocols such as OpenID, WebID, Web Authn, IndieAuth, etc. Some of these do not solve the same problem as DID, but there is some degree of overlap.

On the way to forming a standard for DID, Google, Mozilla, and other big companies of the Internet era raised objections and tried to prevent the formation of the DID specification. Whatever their motives, I believe this just shows the value and potential of DID. It reminds me of the last time I started in the VoIP space, when the big phone companies, communications technology companies and state-run telecoms tried to stifle IP telephony technology, launching wave after wave of sniping at innovation... Today VoIP technology is the basic service and even the new backbone of today's telecoms business. All those "giants" who tried to stop technological innovation either became history themselves or were eventually forced to embrace it and join the new camp... history has always rhymed.

In a discussion on Hacker News about DID Core becoming a W3C Recommendation, I was surprised to see many of these comments focused on the criticism and mockery that resulted from having many blockchain technology companies involved in DID. I have read through dozens of comments and one in particular and have not seen a single "valid" counter-argument, but rather a lot of misunderstanding of DID, misinterpretation and malice towards blockchain and cryptocurrencies. As mentioned earlier, DID and blockchain are actually independent technologies, and they are not necessarily related to each other. But due to the popularity of blockchain, digital currency, and the now trendy Web3 concept, a significant number of blockchain technology companies (including us) have seen the value of DID and have taken the plunge. It is quite surprising and unfortunate that many people in the Hacker News discussion in the geek community are mocking and disgusted by this, but it also shows that DID still has a long way to go before it becomes popular.

Just as if we go back in history to July, when the Declaration of Independence was first written, signed and proclaimed, the United States was still a small and weak political body in the storm, which is still a long way from the United States to grow into a strong country, no one knows that this short declaration in the future will write an indelible history.