did:tag Method Specification

The goal of this proposal is to go beyond the already good work done with other DID methods, particularly the did:web method, and address several issues for which satisfactory solutions are not already provided. The key issues addressed here include:

1. The persistence of identifiers' uniqueness across time.
2. Expanding the realm of DID issuers and resolvers to include all those who have an email addresses but may not have sufficient control over web resources to host web-accessible did documents.
3. Asynchronous access to DID documents.
4. The provision of alternative DID resolution mechanisms.

Persistence: It is generally accepted that ideal decentralized identifiers would be memorable, secure from misuse, and globally unique. But, an identifier should also not become less memorable as time passes, or less secure, or less likely to be unique. Thus, to the set of three basic naming qualities, we should add a fourth quality; that of persistence. [WYMANS-TETRAHEDRON]

Unfortunately, as Zooko Wilcox-O'Hearn [ZOOKOS-TRIANGLE] pointed out in 2001, it is not possible to simultaneously optimize all of the base qualities of decentralized identifiers. For example: identifiers may be secure, global, and even likely to remain so for quite some time, perhaps by using very long cryptographic hash functions to mint them, but such names are typically not very memorable, at least not by human beings. Thus, our process for creating names needs to incorporate a tradeoff between the various desirable attributes of ideal identifiers.

Web DIDs do a good job of addressing three of the desirable qualities of a decentralized identifier. [WEB-DID] The DID Document provides the data needed to make them secure, the ability to structure them with human readable components allows them to be memorable, and their linkage to DNS records provides an ability to ensure that they are unique by limiting the number of those who can mint them.

did:web:example.com:user:alice

However, while an issuer of Web DIDs may work hard to ensure that duplicate DIDs are not issued, maintaining uniqueness over time can be challenging. A Web DID might be issued to a user named Alice in one year, but then Alice may cease to become a user in some future year. Once that happens, some new Alice may wish to have the simple, memorable identifier "user:alice," but be told that that identifier was issued to a long-gone user in some previous year. Alternatively, the new Alice may be assigned the name she desires, thus causing potential confusion for all those who once interacted with the old Alice. Of course, domains tend to change owners over time and a domain owner may not even be aware that there had once been another Alice.

These issues of identifier persistence were considered and addressed in the preparation of the IETF's tagURI scheme. [RFC4151] The solution was to define a scheme, very much like that used for Web DIDs, but with an added component that specifies a date during which the issuer of the identifier claims to have had authority to use the domain name incorporated within the name. Using tagURIs, it is becomes possible to create only slightly less memorable names for multiple Alice's at different times. For instance, the following are several possible tagURIs that might identify different Alice's without conflict. Each of these DID could be minted by a different issuer without a need to know of any earlier issuer who might have had authority to use the same domain name. Each of these DIDs might also have been minted by the same Alice -- although it would generally be preferred if users were consistent in the DIDs they use.

tag:example.com,2000:user:alice
tag:example.com,2050:user:alice
tag:example.com,2090-10-15:user:alice
tag:example.com,2090-10-16:user:alice

In order to gain the benefits of persistence provided by tagURIs, this proposal describes a DID method that relies on tagURIs as its base rather than the web URLs which were the focus of the Web DID.

Enabling all to be issuers: Ideally, everyone would be able to generate useful DIDs without needing to rely on other issuers or needing to invest in complex technical capabilities such as those provided by virtue of obtaining a DNS domain name and operating a web site. Unfortunately, most existing DID methods assume that an issuer has ready access to capabilities that are not commanded by the vast majority of users. Even something as "simple" as registering domain name and maintaining a web site to host DID documents is far beyond the capacity of many. Nonetheless, individuals will often need to generate identifiers.

While only a small percentage of those who may need to issue DIDs maintain, or could maintain, their own web sites, almost every user of the Internet has a unique email address that can be used to exchange content with others. And, crude as it may seem, the email protocol provides much the same ability to engage in "request/response" exchanges as is provided by the HTTP and similar protocols. Thus, the needs of users without web sites could be addressed by providing a mechanism for minting DIDs from tagURIs which incorporate an email address rather than a domain name. For instance, the following are valid tagURIs incorporating email addresses:

tag:john@example.com,2000:sender_key
tag:paul@example.com,2021:living_room_tv
tag:admin@example.com,2022:
tag:lookup@example.com,2022:vp_sales

Each of these tagURIs can be easily converted into a DID, using the tag method, by simply prepending the text did:.

The simplest way to support such email-based DIDs would be to define a resolution method that allows one to send an appropriately structured email message to the specified address. The appropriate response to such a message would be another email message containing the requested DID Document as an attachment. Such a system could be implemented by having custom software monitor and respond to messages sent to a particular email inbox. It could also be implemented using completely manual means. A "john@example.com" might receive a message with a subject of RESOLVE: did:tag:john@example.com,2000:sender_key and know that the desired response was an email with the corresponding DID document as an attachment. With only a little difficulty, the appropriate response could be prepared and sent.

Asynchronous Resolution: An email based DID resolution method, unlike a web-based method, allows asynchronous DID resolution. In some cases, the resolution might occur hours, days, even weeks after a resolution request was made. But, even a very slow response might actually be the fastest possible response. An asynchronous resolution capability would be particularly useful in environments when connectivity is difficult to maintain or where bandwidth is very slow. As an extreme example, it is very unlikely that one would be successful in using https to fetch a DID document from a web server in New York City if one were making the request from a habitat on Mars or one of its moons.

Alternative DID resolution mechanisms. Just as web addresses can sometimes be temporarily unavailable due to technical issues, a web address's availability is sometimes limited by local or regional administrative policy. One's employer, or one's government, might block web access to sites that traffic in either pornography or discussions of human rights and liberty. However, even though a user may be blocked from directly accessing a web site, and thus from resolving DIDs normally resolved by doing so, it is often the case that it is possible to exchange email with addresses on that site, if only because email doesn't require direct, point-to-point connections. Thus, it is useful to define a mechanism by which even a normally web-accessible DID document could be retrieved via indirect, asynchronous email protocols. In order to provide this mechanism, I propose that an ``AltResolution'' service be provided as a means to inform users of an alternative to web-based DID resolution that may be employed when web-based resolution is ineffective.

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:tag:example.com,2021-10-26:Bob",
  "verificationMethod": [{
    "id": "did:tag:example.com,2021:faHiOpRlPVQcY_-tA4A",
    "type": "JsonWebKey2020", 
    "controller": "did:tag:example.com,2021:123",
    "publicKeyJwk": {
      "crv": "Ed25519", 
      "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ", 
      "kty": "OKP", 
      "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A" 
    }
  }],
  "service": [{
    "id": "did:tag:example.com,2021:asynch",
    "type": "AltResolution",
    "serviceEndpoint": "mailto:did@example.com"
  }],
}