DID Delegation
In today’s interconnected world, the concept of digital identity is becoming increasingly significant. One revolutionary approach that is gaining traction is Decentralised Identifiers (DIDs), a cornerstone of decentralised identity technology. In this context, we’re going to focus on one key aspect of DIDs – DID Delegation.
What are Decentralised Identifiers (DIDs)?
To understand DID Delegation, we first need to grasp the concept of DIDs. DIDs are globally unique identifiers that are created, read, updated, and deactivated by their owner without requiring a central registry or authority. They are typically associated with a set of cryptographic keys, allowing the owner to prove control over the DID.
What is DID Delegation?
DID Delegation is a concept that allows the owner of a DID to delegate certain rights or capabilities to another entity. This delegation is done in a cryptographically secure and verifiable manner. It’s like handing over a digital power of attorney, where the delegator assigns some of their authority to another party, known as the delegatee. In the W3C DID Core Specification DID Delegation is described as:
The
capabilityDelegationverification relationship 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.
Why is DID Delegation Important?
DID Delegation is crucial for several reasons:
- Flexibility: Delegation allows DID owners to flexibly manage their digital identities. They can delegate specific tasks to other parties without giving up total control.
- Scalability: DID owners can delegate responsibilities to multiple parties, making it easier to manage larger systems and networks.
- Security: Delegation maintains security by ensuring only authorised parties can perform specific tasks. The delegator can also revoke access if necessary, maintaining control over their digital identity.
- Privacy: DID Delegation can help enhance privacy by enabling the delegator to limit the information shared with the delegatee to only what is necessary to perform the delegated task.
How Does DID Delegation Work?
DID Delegation for did:oyd involves a few key steps and are described below using the command line utility oydid:
- Creating a Delegation Record: The delegatee creates a delegation proof using their private key and publishes it in the DID Log. This entry in the log record includes the public key and explicitly states the rights or capabilities to be delegated.
oydid delegate --doc-enc z6M... did:oyd:zQm...
Note: the response of the command is the log reference (hash value) of the newly created records
- Confirming the Delegation Proof: While the first step only publishes a delegation record (that can be done by anyone) the DID owner needs in the next step to confirm / sign the delegation record for inclusion
echo '["log-reference"]' | oydid confirm did:oyd:zQm...
Note: the input is an array of log-references to be included
- Using the Delegation: The delegatee can now act on behalf of the delegator within the bounds of the delegated rights. When a delegatee performs an action, he/she provides the delegation proof, which can be verified using the delegator’s public key. To retrieve all currently active public keys you can use the following command:
oydid pubkeys did:oyd:zQm...
Examples for the use of delegation in the did:oyd method infrastructure are retrieving Verifiable Credentials from the online wallet or updating a DID Document itself.
Here is an example DID Document with delegation information (for did:oyd:zQmRTHTMPvbaEuvSDfsZZhWkMdaJNS2Zzy73sg3g4BzJo95):
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
],
"id": "did:oyd:zQmRTHTMPvbaEuvSDfsZZhWkMdaJNS2Zzy73sg3g4BzJo95",
"verificationMethod": [
{
"id": "did:oyd:zQmRTHTMPvbaEuvSDfsZZhWkMdaJNS2Zzy73sg3g4BzJo95#key-doc",
"type": "Ed25519VerificationKey2020",
"controller": "did:oyd:zQmRTHTMPvbaEuvSDfsZZhWkMdaJNS2Zzy73sg3g4BzJo95",
"publicKeyMultibase": "z6Mv9jNrbButvkd6rcR6cjH5q3XnNi8sLncxK3y5HWCvVcfd"
},
{
"id": "did:oyd:zQmRTHTMPvbaEuvSDfsZZhWkMdaJNS2Zzy73sg3g4BzJo95#key-rev",
"type": "Ed25519VerificationKey2020",
"controller": "did:oyd:zQmRTHTMPvbaEuvSDfsZZhWkMdaJNS2Zzy73sg3g4BzJo95",
"publicKeyMultibase": "z6MutbEUJQkFCDQiYS9Ccb9acLvs7MvrSiYRmkQTMqv2srq6"
}
],
"capabilityDelegation": [
{
"id": "did:oyd:zQmRTHTMPvbaEuvSDfsZZhWkMdaJNS2Zzy73sg3g4BzJo95#key-delegate-doc-1",
"type": "Ed25519VerificationKey2020",
"controller": "did:oyd:zQmRTHTMPvbaEuvSDfsZZhWkMdaJNS2Zzy73sg3g4BzJo95",
"publicKeyMultibase": "z6Mv2qS3ntVzPo5gvZQa3Sq3DYRr8CRujTD65riMV5seqanF"
}
],
"alsoKnownAs": [
"did:oyd:zQmNZh64xxX3vt3FrZuo2MzmKUDcpSNbWDVd54Dg8rqKey5"
]
}
Findings Along the Way
Implementing delegation for the did:oyd method provided some insights and learnings that might also be relevant for other DID methods:
Describing Capabilities
While the W3C DID Core Spec has dedicated Verification Methods for Capability Invocation and Capability Delegation, I could actually not find a way to describe a capability itself. In the did:oyd method there is the possibility to delegate the capability associated with the document-key (to be used e.g. when establishing a secure communication channel with DIDComm) and for the revocation-key (necessary to publish an update of the DID Document). In addition it would make sense to have dedicated cryptographic material in a DID Document associated with service endpoints and consequently allow delegation for accessing a service.
This might be addressed in upcoming versions of the DID Specification to allow a more explicit referencing of capabilities.
Available Capability Delegation in Other DID Methods
When searching for Capability Delegation in other DID methods I found surprisingly litte information. Reading the specifications in the DID Method Registry actually made me aware that the use of Verification Methods is not part of the typical DID Method Specification and I assume that those are interpreted quite differently in the various implementations. Which brings us to the final finding:
DID Rotation
Migration between different DID methods is hard – at least I’m struggling for a while now to implement such a functionality for did:oyd. And with implementing more functionalities like Capability Delegation it becomes even harder since it would require to research and develop peculiarities for each other DID method. This might be an area that the upcoming DID Resolution Specification could address.
For now I made the design decision for did:oyd that any capability delegation needs to be explicitly renewed upon updating a DID Document, i.e., the default behaviour when publishing a new DID Document is to automatically disable any previous delegations.
In conclusion, DID Delegation is an essential component of decentralised identity systems, providing flexibility, scalability, security, and privacy. This blog posts described how DID Delegation works for the did:oyd method and explained the various mechanisms involved in the process.
A bold new initiative to shape the new normal of data has arrived – MyData Operator 2020 status awarded to OwnYourData.
