Understanding SSI components -DID Document

The previous articles covered an overview of SSI and how a self generated ID along with a cryptographic authentication method allows us to have a Distributed, Persistent, Globally Unique and Verifiable identifier — the DID.

The DID is a pointer to your digital identity, similar to how a legal name is a pointer to your real world identity. The complete identity profile that the name points to, includes many other data points such as address, qualifications, phone number, email etc.

To be able to support such an identity profile, SSI specification defines a data structure called DID Document. It contains data points such as.

• DID Subject : This is the DID of the entity being identified. It could be a person, an organization, an object or even a concept.
• DID Controller: DID of the entity that can modify the DID Document, and hence controls it.
  Mostly this is same as the DID subject, but could be different in certain scenarios, for e.g., in a DID document for a minor being controlled by a guardian.
• Authentication Methods: These are methods that the subject of the DID Doc can use to authenticate itself. E.g., by producing a digital signature corresponding to the public key mentioned here.
  A DID Doc may define multiple such methods of varying complexities.
• Verification relationships: This section maps the authentication methods defined above to authorization of specific operations related to the identity.
  For e.g., method #1 for Authenticating self, method #2 for signing documents etc.
• Services: This section allows to express ways in which other parties can communicate with the DID subject. This could even be the subject’s contact number or email address. But in case the DID document is going to be public, its advisable to not share any personally identifiable information.

Below is a simplified example of a DID document for an adult person.

{
"@context": [
... array of JSON-LD contexts
]
// DID identifying the subject
"id": "did:example:123456789abcdefghi",    
// DID of the party controlling this DID Document
// For an adult it is same as 'id', but incase of a minor, it could be
// set to a guardian's DID
// optional field, controller defaults to 'id' if not set
"controller": "did:example:123456789abcdefghi",  
"verificationMethod": [{
"id": "did:example:123456789abcdefghi#key-1",
// algo used for key generation
"type": "Ed25519VerificationKey2020", 
// controller of the private key, same as the subject in this case
"controller": "did:example:123456789abcdefghi", 
// public key to be used for signature verification
"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" 
}, 
...],
"authentication": [
// this is a type of 'verification relationship'
// a relative DID URL is used to reference a verificationMethod above.
// An entity that can provide a valid signature for key-1 is considerd to
// be authenticated
"#key-1"
],
"services": [
// defines the domain controlled by this identity 
{
"id":"did:example:123456789abcdefghi#linked-domain",
"type": "LinkedDomains", // specifies service type as a web domain
"serviceEndpoint": "https://bar.example.com"
}]
}

You can imagine how the identity owner, with the help of DID Document, can

• Rotate the keys by updating the authentication methods while continuing to use the same DID
• Delegate control to another party using the controller field, and
• Advertise service endpoints that can be used by others to initiate communication