Simple Decentralized Identifier (DID) Document Hosting on Azure
Decentralized identifier documents are a new type of digital identity document that enable verifiable and decentralized interactions between any subject and any other entity, without relying on any central authority or intermediary. They are self-sovereign, resolvable, and based on the Decentralized Identifiers (DIDs) v1.0 specification by the World Wide Web Consortium (W3C). One of the methods to create and use them is the did:web method, which leverages the existing web infrastructure and security protocols to host a JSON-LD file at a standard HTTPS URL, meaning they can be hosted and distributed globally using Azure, which is what we will be doing in this article.
Prerequisites
Will be using Terraform and its azurerm and cloudlare providers to deploy the environment, so we will be needing the following installed on our workstation:
Note that we will need a Cloudflare account and a domain in that account for this.
Example Repository
A complete Terraform script that creates a resource group, a storage account (for a static web site), an Azure CDN instance and a Cloudflare CNAME DNS record, and then uploads various JSON-LD DID documents, can be found in the following GitHub repository:
Deployment Script
We will start by reading the Cloudflare zone and creating a resource group:
Then create a storage account which will be used to store the documents:
Next, we create the Azure CDN profile and endpoint to distribute the documents globally:
And lastly create the CNAME record and CDN custom domain configuration to point to the CDN endpoint:
Now that we have the resources, it is time to upload the JSON-LD DID documents. Note that the DID must match the domain name, having a root DID URI like did:web:eample.com means there must be a did.json file available at the URL https://example.com/.well-known/did.json. For non-root documents, the route in the DID URI did:web:eample.com:sub-docs:doc-a must represent the actual route of the document where it is hosted like so https://example.com/sub-docs/doc-a/did.json (more on the did:web method specification can be found here).
We will use a template for the root document that can look like this:
And a template for each document hosted in a subdirectory that might look like this:
Note that both templates have the domain variable defined, so the document can be set with the actual domain used, and in the template that will be used for a document hosted in a subdirectory, there is an additional route variable for setting the documents route to match the path in storage.
Will upload one document to the root, and have an additional looped resource to upload documents in subdirectories:
Testing The Deployment
To check that everything was deployed as expected, we only need to open a browser and point to the correct URLs using the domain we used, like https://example.com/.well-known/did.json for the root document and https://example.com/route/to/doc/did.json for a document that was placed in the route/to/doc route.
Conclusion
There are many more DID method specifications, which might be more suitable for other scenarios and systems, so make sure to check the complete list of methods, which can be found here.
