Understanding SSI components -DID Document
Links to previous posts in the series
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
The DID and the DID Document form the complete identity profile of an entity. One would need access to both, to be able to form a meaningful relationship.
The simplest method would be to share the DID and the DID document peer-to-peer over existing channels such as HTTP/HTTPS. This would be the most decentralized mechanism. But the system also needs to be trustless, hence the recipient needs to always verify the received document, which would be a complex and time consuming process.
The P2P method still suits well for Peer to Peer connections. However consider a large organization like Google that needs to form billions of relationships with individual users. Can we avoid each user having to repeat the DID document authenticity and integrity check?
What if there was a data registry that was
- Distributed: so that the DID Doc is also persistent like the DID
- Trust-less or consensus based : So there is censorship resistance
- Immutable: so that the integrity of DID doc is guaranteed
- Rule based: so that only rightful owner can create and update the DID document
Blockchains fit the requirements well, and hence most of the DID Methods use them as a ‘Verifiable Data Registry’. Now an org can place their public DID Document on the data registry. Anyone who needs the DID Doc can fetch it by querying the registry with the DID — this process is called DID Resolution.
However some of the DID methods do not use a blockchain, and even for the ones that do, how does a resolver know from which blockchain and how to obtain the DID Doc?
As mentioned in previous posts, the DID also includes the DID Method
did:<did-method>:<method-specific-identifier>
The resolver software parses the did to extract DID Method string and accordingly determines the steps to fetch the DID Doc. For e.g.
- did:web: indicates the DID Doc is to be fetched from a web URI
- did:ethr: indicates the DID Doc is on the Ethereum blockchain
The SSI handshake between a user and and Google would now look as follows
- The user gets Google’s DID from a trusted source
- Based on the DID Method embedded in the DID, the user resolves the DID to get DID document
- Data in the DID Doc can be used to establish a secure connection with Google. For e.g., it could have ‘Linked Domains’ configured under services which ensures you are using the authentic URL thus avoiding fishing attacks
- This connection can be used to share the users DID and DID Doc with Google enabling a bidirectional link.
Below diagram from W3C Spec shows the relation between basic components of SSI
As of now we have established
- How a user can create a Distributed, Persistent, Unique and Verifiable identifier, i.e. DID
- How a DID Document is used to attach metadata to a DID
- How the DID Documents are shared between parties using Verifiable data registries
These steps allow us to establish a peer to peer connection between two parties that is secure, censorship resistant and persistent.
In the coming articles we will understand how this base setup can be used to share endorsements about the identity in the form of Verifiable Credentials using the DID Comm communication protocol
