Table of Contents
As we covered in the Platform Core - DIDs introduction, Decentralized Identifiers (DIDs) are a standards based way of allowing a person, group or organisation (or even a thing) to uniquely identify themselves.
This tutorial will demonstrate how to use Decentralized Identifiers on the platform, which generally means they will be used in Issue and Verify VC flows. The sorts of DID that can be issued on the platform have different properties and some are better suited to some use-cases over others. As yet, we have not uncovered the perfect DID method so getting a good understanding of the different offerings will help you decide which is going to work best for your situation.
DIDs are actually just URIs, they follow a certain pattern and they resolve to a DID Document.
Example of a basic did:key
The DID Document is best thought of as a place to hold Public Keys and some other metadata, it may contain service endpoints.
DIDs are meant to be public, they can be shared and even published on your own website as metadata.
In the background, the platform will create new keys for the DID (some of our DID methods allow you to specify the key type), the private key is stored securely on your tenant and the public key is made available in the DID Document.
Look through each of the DID methods to find out how to successfully setup a DID once you have created one, then follow the other tutorials to put the newly created DID into practice by Issuing a credential.
We're also actively investigating Sidetree protocol DIDs, did:ion and did:elem, check back as we offer more information on these interesting protocols as they develop.