In my last article “Self Sovereign Digital Identity: How it works?”, I had shown the use of various concepts like DIDs, DID Documents, Verifiable Credentials (VCs), etc. to provide privacy preserving security. In this article, I am diving deeper into the DID and DID Documents.
The decentralised identifiers are globally unique identifiers. The subject(entity, user, holder) chooses a system (software) that they trust to generate this unique identifier. The software may be running on the devices that they possess or provided by a provider as service. Such providers are referred to as “method”. The software running on the device is referred to as agent. The format of these identifiers has three parts — it always starts with “did”, the first part, which indicates that it’s a decentralised identifier (DID). The remaining two parts depend on how they get generated.
- When generated using the agent — “did:peer:unique-identifier”: The second part is always “peer” indicating that it’s generated using the agent running on user device. This is typically used for private and one-to-one relationship between two entities. The unique identifier is a globally unique identifier generated by the agent. The agent implements an algorithm to be able to generate such unique identifiers. The details of the algorithm can be found in the “Peer DID Method Specification”
- When generated using a provider — “did:did-method:method-specific-unique-identifier”: The “did-method” is usually a service provider that maintains a VDR (Verifiable Data Registry) and implements operations to create and maintain DIDs in the VDR. This is typically used to create public identifiers or when a user wants to share the identifier with more than one entity. The “method-specific-unique-identifier” is unique in the context of he did-method.
Often, there is a DID Document associated with the DID. The DID Document contains information that can be used to interact with the entity in a private and secured way. It doesn’t or should never contain any personal data, either directly to indirectly like through references.
A typical digital interaction of a user involves Authentication and Service Access.
The DID document provides option to specify the cryptographic public key that can be used to authenticate the user. The authentication typically uses a challenge response protocol. The figure1 below shows the use of keys from the DID Document and the challenge response protocol to establish mutual authentication between subject (user, entity, holder) and verifier.
In the above example, the DIDs for both subject (Alice) and verifier (DPS) were generated using a provider (method). In case the DIDs were generated using agents, the flows would be same except the source of the DID Documents. In that case, the DID Documents could have been already exchanged when the peer relationship was established or could be exchanged while requesting for the service, and stored on their devices.
This is a basic example of challenge response protocol. There are many variations which can be more complex that provide stronger security. However, all of these variations depend on the public keys specified in the DID Document.
Let’s suppose DPS provided “Login History” service, and Alice wanted to access it. This service was protected, and could be accessed by authorised users sonly. Let’s suppose that she was provided with an access token after successful authentication. She would need to pass this token to DPS to be able to access “Login History”. The Figure2 below details the Service Access flows.
Both of these scenarios, Authentication and Service Access, used cryptographic keys to verify the authenticity of the user. The DID Document specification terms the use of cryptographic keys for the purpose of authentication and authorisation as verification methods. It recommends the use of different keys (verification methods) for different purposes. These different purposes are termed as verification relationships. The specification has defined the following verification relationships.
- Authentication: It is used to specify how the DID subject is expected to be authenticated, for purposes such as logging into a website or engaging in any sort of challenge-response protocol. [I covered this in this article.]
- Assertion: It is used to specify how the DID subject is expected to express claims, such as for the purposes of issuing a Verifiable Credential. [I will cover this in detail in my next article.]
- Key Agreement: It is used to specify how an entity can generate encryption material in order to transmit confidential information intended for the DID subject, such as for the purposes of establishing a secure communication channel with the recipient. [I will cover this in detail in one of my up coming articles.]
- Capability Invocation: It is used to specify a verification method that might be used by the DID subject to invoke a cryptographic capability, such as the authorization to update the DID Document. [I covered this in this article.]
- Capability Delegation: It is used to specify a mechanism that might be used by the DID subject to delegate a cryptographic capability to another party, such as delegating the authority to access a specific HTTP API to a subordinate.
The specification provides security recommendations to preserve privacy while securing digital interactions. Here are my takeaways from the document.
- Like stated above, the DID Document should not contain any personal data. Rather the specification provides an option to specify service endpoints that are under the control of the user, and can be used to retrieve additional information or interaction options with the subject. The other option for sharing personal data is using Verifiable Credential (VC). [I will cover VC in my next article. ]
- Like any type of globally unambiguous identifier, DIDs might be used for correlation. DID controllers can mitigate this privacy risk by using pairwise DIDs (peer DID) that are unique to each relationship; in effect, each DID acts as a pseudonym. The anti-correlation protections of pairwise DIDs are easily defeated if the data in the corresponding DID documents can be correlated. For example, using identical verification methods or bespoke service endpoints in multiple DID documents can provide as much correlation information as using the same DID. Therefore, the DID document for a pairwise DID also needs to use pairwise unique information, such as ensuring that verification methods are unique to the pairwise relationship.
- Following the concept of herd privacy, a better strategy for endpoint privacy might be to share an endpoint among a large number of DIDs controlled by many different subjects. It is the goal of herd privacy to ensure that the nature of specific DID subjects is obscured by the population of the whole. To maximize herd privacy, implementers need to rely on one — and only one — service endpoint, with that endpoint providing a proxy or mediator service that the controller is willing to depend on, to protect such associations and to blind requests to the ultimate service.
- External links are to be avoided if they cannot be integrity protected and the DID document’s integrity is dependent on the external link.
In essence, DIDs are an enhanced form of URN (Uniform Resource Name) that provide a cryptographically secure, location-independent identifier for a digital resource, while also providing metadata that enables retrieval. Due to the indirection between the DID document and the DID itself, the DID controller can adjust the actual location of the resource — or even provide the resource directly — without adjusting the DID. The use of cryptographic keys allows to preserve privacy while providing security. With advancement of technology, creation and maintenance of cryptographic keys are not major challenges anymore. [This reminds me film photography vs digital photography. In the former case we had to be very careful about taking pictures because of limited resources. Whereas in the later case that constraint is not there almost.]
In summary, the essential properties of DID Document that facilitate secured interaction with the DID subject while preserving privacy are
- Id: This is the subject identifier (DID)
- verificationMethod
- authentication
- assertionMethod
- keyAgreement
- capabilityInvocation
- capabilityDelegation
- service
The other properties of the DID Document are: alsoKnownAs, and controller that provide more extensibility and flexibility for the use of DIDs and DID Documents. The specification itself goes into more implementation and technical details.
