TL;DR

  • Dock DIDs now support more than one key
  • Keys can be given different capabilities using Verification Relationships
  • We support 4 Verification Relationships: Authentication, Assertion, Key Agreement, and Capability Invocation.
  • DIDs can now be controlled by other DIDs
  • DIDs can now have service endpoints
  • Dock now supports off-chain DID Documents

Until now, Decentralized Identifiers (DIDs) on Dock could only have one key at any moment. Though they could be rotated over time, having only one valid key at any moment meant that the DID owner had to use the same key for all purposes.

As an example, consider the life of an issuer utilising a DID. The issuer could perform several functions like the issuance of credentials, authenticating with some other application, engaging in secure communication using a methodology like DIDComm, or revoking its issued credential on the blockchain, which again requires authenticating itself to the chain. Following the principle of separation of concerns, the issuer would ideally like to have separate keys for each of these functions so that when one key is compromised or lost, its other functions are not impacted. Also, the issuer would like to have separate more sensitive keys that can be used to add new or remove existing keys of its DID.

Keys and Verification Relationships

With the latest release of our platform (blockchain node and SDK), we enable a DID owner to have a setup like the above. This new release will allow a DID to add multiple keys for its DID and give them different capabilities. These are called Verification relationships in the W3C DID spec. A key can have one or more Verification relationships to the DID depending on the kind of functions it's supposed to perform on the DID's behalf.

We support 4 Verification Relationships:

1. Authentication - Keys with this relationship are only allowed to be used for authentication, i.e. convincing the other party that it's a key of the DID. Such a key can revoke a credential on the blockchain, add a schema, or act as a holder when sharing a presentation of credential(s).

2. Assertion - Keys with this relationship are used for signing credentials during issuance.

3. Key Agreement - These keys are used during secure communication to encrypt some data for the DID.

4. Capability Invocation - These keys are able to modify the DID Document, i.e. add new or remove existing keys, add/remove service endpoints, controllers (more on this below), etc. If a DID has one or more such keys, we say that the DID "controls" itself, meaning that it can modify its DID Document. We have intentionally decided to allow keys with this relationship to also add schemas, revoke credentials, etc., on the chain.

While adding a key, it can be specified what verification relationships the key would have with the DID. Each new key gets a unique id (in that DID's context), and using this id, the key can be removed as well.

DID Controllers

As mentioned above, only keys with "Capability Invocation" are able to modify the DID Document. A DID with such a key is said to be self-controlled, or it's a controller of itself. But a DID might have other controllers as well, or a DID might not control itself but is only controlled by other DIDs. This capability is essential for guardianship use cases where a DID (the controller) is the custodian of another DID (controlled).

As an example, consider an organization that wants to onboard its members to our chain and give each member a DID. At the time of onboarding, members might not be capable of managing keys, so the organization will create a DID for each of its members. That member DID won't have a key, and the organization DID will be the controller of the member DID. Now the organization is the guardian of the member.

When the member becomes capable of managing keys, the member will provide its public key to the organization, which will update the member DID with that public key, make the member the controller of its DID and remove itself from the controller role, thus ending the guardianship.

In another example, consider an IOT application where each sensor has its own DID. The sensors have keys that they use to sign (Authentication) messages before sending or decrypting (Key Agreement) received messages, but only the owner of the sensors can update their keys. Also, the owner could add new owner(s) to those sensors by adding more controllers to their DID or remove itself as the controller, thus transferring the ownership.

Similar to sensors, DIDs can be assigned to other objects like batteries where batteries have DIDs, but they don't have any keys, only controllers (the owner of the battery). This helps us in building Digital Product Passports which are digital twins of physical products to enable a sustainable and circular economy, etc. DIDs can also be assigned to an NFT where the NFT itself has no keys, but the owner of the NFT is the controller of its DID. When the ownership is transferred, the controller of the NFT DID also changes (this will be triggered through a smart contract).

Other Features of This Release

Service Endpoints

DIDs often need a way to communicate, like a subject DID needs to request a credential from the issuer DID. The issuer thus needs a way to publish its contact information like an HTTPS endpoint it should be reached on or its website. This is achieved by the issuer adding a "service" to its DID Document, which specifies this information. As alluded to before, only controllers of a DID can update the DID Document, thus adding the service endpoint.

Off-Chain DID Documents

Another feature we have added is off-chain DID Documents. Until now, all things part of the DID document, like keys, controllers, and services, are stored on the chain. The logic to add/remove these is not clearly defined in the DID spec but is what looked like the most reasonable to us. But for users who would like a different set of rules for updating DIDs or adding more functionalities without waiting for us to build them can host their DID documents on another storage like IPFS or anything and only store the reference to the document like IPFS CID or URL for the DID.

Improvements and Changes

Lastly, the release contains several refactorings and improvements, which led us to introduce breaking changes, so please upgrade your applications at your earliest convenience.

For a more technical walkthrough of these features check out the conceptual explanation and the hands-on example. Also, there are breaking changes for our SDK so please use SDK version 2.3.0 or above.

Learn More