Latest News
Updates from the OwnYourData team.
Updates from the OwnYourData team.
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.
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.
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
capabilityDelegation
verification 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.
DID Delegation is crucial for several reasons:
DID Delegation for did:oyd involves a few key steps and are described below using the command line utility oydid
:
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
echo '["log-reference"]' | oydid confirm did:oyd:zQm...
Note: the input is an array of log-references to be included
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" ] }
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.
OwnYourData and the Kybernos ESG Data Services GmbH are taking part in ONTOCHAIN, to co-develop a new software ecosystem for trusted, traceable & transparent ontological knowledge
WHAT IS ONTOCHAIN?
ONTOCHAIN is a new software ecosystem for trusted, traceable & transparent ontological knowledge management funded by the European Commission as part of the Next Generation Internet initiative (NGI).
ONTOCHAIN empowers internet innovators to develop Blockchain-based knowledge management solutions that address the challenge of secure and transparent knowledge management, as well as service interoperability on the Internet.
The ONTOCHAIN software ecosystem aims to demonstrate its potential in high impact domains, such as eHealth, eGovernment, eEducation, eCommerce, decentralised infrastructures and similar, in order to achieve trustworthy information exchange and trustworthy and transactional content handling.
Babelfish is taking part in ONTOCHAIN to provide service integration in heterogeneous environments. Our project proposes to describe services on a technical, semantic, and governance layer and will implement a component that uses such descriptions to translate interfaces (APIs), data, and data agreements from a foreign (and maybe proprietary format) to an interoperable format understood by the recipient. A registry maintains a list of all services and thus spans up an interoperable data space.
HOW WILL IT WORK?
ONTOCHAIN Open Call 3 was looking for interoperable and sustainable applications that employ Semantic Web and Blockchain concepts, to enhance data quality aspect, as well as the trustworthiness of data communication and handling processes.
Web3 innovators were invited to propose applications covering real needs of end users in vital sectors of the European economy, built on top of the software services of the ONTOCHAIN ecosystem. Applicants could also submit proposals around missing blocks of the ONTOCHAIN infrastructure.
A total of 105 projects applied for the call and the evaluation process resulted in the selection of 14 proposals addressing the following topics:
ONTOCHAIN INFRASTRUCTURE
ONTOCHAIN APPLICATIONS
ONTOCHAIN will support Babelfish through a 10-month programme and provide funding support up to 119.500 Euros. As part of the action, experts in diverse fields will also provide technology development guidance, working methodology, as well as access to top infrastructure, coaching, visibility and community building support.
FOLLOW OUR JOURNEY THROUGH ONTOCHAIN!
Take a look at the ONTOCHAIN innovators portfolio to see more information about the projects selected. For the Babelfish project find also detailed information at websites from OwnYourData and Kybernos.
To read more about ONTOCHAIN please visit the website: ontochain.ngi.eu.
One of the goals in our current FFG-funded project IDunion was to develop a framework for managing different data models of Covid19 Credentials. In the course of our project we implemented this functionality through the Semantic Overlay Architecture (SOyA 🌱) and this blogposts provides an introduction to this new technology.
There are currently a few initiatives around the world that want to develop digital vaccination records and bring them to market. However, the past has shown that even established solutions such as the international vaccination certificate (“Yellow Card”) cannot be digitized so easily.
This blog post summarizes the key highlights of the Digital Immunization Passport (DIP) project. We implemented and evaluated an end-to-end workflow for handling immunization information in a human-centric way, and we provided the necessary infrastructure for all participating stakeholders to demonstrated the functionality in real-world use cases: Yellow Fever and Tick-borne encephalitis vaccination. The project […]
OwnYourData & Human Colossus Foundation have been selected for the 2nd phase in the Data Portability & Services Incubator (DAPSI) to continue development of the Digital Immunization Passport project. From September 2020 to January 2021 we developed the first version of a Digital Immunization Passport for Yellow Fever and demonstrated the feasability of such a […]