Trust Over IP

Full Title or Meme

One means of enabling trust which was introduced by the Verifiable Credential folk as Rebooting the Web of Trust.

Context

The ToPI

• did:webs Method Specification. (2023-12-15)

When DIDs were first invented, the inventors thought that someday there might be perhaps a dozen or so different types of DIDs, called DID methods. Their reasoning was that DIDs solved a very narrow problem—how to create a cryptographically-verifiable identifier—an identifier over which the controller (person, organization, device, bot, etc.) could prove control by virtue of having the associated private key. This new type of identifier would not need to be registered with any centralized authority and could not be spoofed or taken away by some other party (unless they could steal the private key).

Each DID method was simply a different way of specifying how the DID could be securely bound to a public/private key pair. While there are of course multiple ways to do that, what the DID inventors didn’t anticipate is: a) how badly cryptographically verifiable identifiers were needed, and, as a consequence, b) how many DID methods would be created. By the time the DID specification reached a final vote at the W3C in 2022, 112 DID methods had been registered in the W3C DID Spec Registries. As of this writing, there are now 184. That’s 184 different ways to create a DID and resolve it to its corresponding DID document (which is where you find the current public key together with other metadata such as the network service endpoint where you can communicate with the controller). Given this massive number of options, it is no surprise that many developers threw up their hands and chose the one that seemed the easiest and most familiar: the did:web method.

What makes the did:web method so intuitive is that all it requires is posting a DID document on a web server. The resulting DID is simply: a) the string did:web: followed by the domain name of the web server and—optionally—the path name to the DID document (with each forward slash turned into a colon). Here’s a simple example: if the DID document will be stored at the URL:

https://example.com/user/alice

…then the corresponding did:web DID is:

did:web:example.com:user:alice

Of course this is not decentralized since it depends on DNS domain names which require centralized registries. As a result, it inherits all of the security flaws of DNS, and then adds the additional vulnerabilities of storing a “naked” DID document on a web server. Since the DID document contains the public key associated with the DID, anyone who can manage to replace the real DID document with their own version can completely hijack the DID. For these reasons, once DID adoption started to kick in, it came as somewhat of a shock that did:web was proving to be so popular. In fact, some DID proponents became quite worried that the security vulnerabilitiess with did:web might lead to an exploit. Thankfully, as those concerns mounted, by the summer of 2023, no less than four independent groups all had the same basic insight: the vulnerabilities in did:web could be fixed by tunneling a self-certifying identifier inside a did:web string.