IM4DEC: Identity Management for Digital Emergency Communication has been selected for funding as one of the brightest projects for building the Next Generation Internet in Europe

OwnYourData and DEC112 are taking part in TRUSTCHAIN, to co-develop a new software ecosystem for fostering a human-centred, trustworthy, and sustainable internet


The spirit of the first-generation Internet based on individual freedom, material progress, and moral community is slowly turning into individualism, materialism, and moralism, diverging from essential ethical and democratic principles that should underline this technology. The design choice of the past, based on a mix of centrally managed networking and device technologies makes today’s Internet obsolete when it comes to empowering all citizens to act for a more environmentally friendlier digital transformation, as well as to create a more resilient, inclusive, and democratic society, addressing inequalities and human rights, better prepared for and responsive to threats and disasters.

For these reasons, TrustChain’s overarching goal is to build a portfolio of Next Generation Internet protocols and an ecosystem of decentralised software solutions that uphold the highest human ideals, including those set forth in the United Nations’ charter, including respect for human rights, ethics, sustainability, energy efficiency, our care for the environment, and our respect for the history of cultures around the world.

Through its 5 Open Calls, TrustChain will address a number of issues including dependable and trustworthy digital identification, robust, secure, and trustworthy data pathways, data economics and trade, energy-efficient data storage, transport, and sharing, and seamless services and data flows.

A total of 100 projects applied for the call and the evaluation process resulted in the selection of 13 proposals. IM4DEC is one of the 13 funded projects and will implement and evaluate an important advancement for Decentralised Identifiers: DID Rotation together with relevant standardisation and validation for the DID Resolution process. Furthermore, it provides the technical (Registration Service) and legal (DPIA) basis for individuals to use DIDs. All of this embedded in the highly relevant emergency services domain to support minorities and the oppressed.

TRUSTCHAIN will support IM4DEC through a 9-month programme and provide funding support up to 115.000 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.



Take a look at the TRUSTCHAIN innovators portfolio to see more information about the projects selected. For the IM4DEC project find also detailed information at websites from OwnYourData and DEC112.

To read more about TRUSTCHAIN please visit the website:

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 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.

Why is DID Delegation Important?

DID Delegation is crucial for several reasons:

  1. Flexibility: Delegation allows DID owners to flexibly manage their digital identities. They can delegate specific tasks to other parties without giving up total control.
  2. Scalability: DID owners can delegate responsibilities to multiple parties, making it easier to manage larger systems and networks.
  3. 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.
  4. 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:

  1. 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

  2. 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 

  3. 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": [
  "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": [

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.

NGI ONTOCHAIN Funding for Babelfish

Babelfish: Service Integration in Heterogeneous Environments has been selected for funding as one of the brightest projects for building the Next Generation Internet in Europe


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


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.


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:


  • Service Integration (Gateways APIs) for ONTOCHAIN applications
  • Energy-efficient and sustainable hosting infrastructure for the ONTOCHAIN software ecosystem and services


  • Semantic Digital Logbooks for Companies, Buildings, Cars or similar
  • Decentralised Fact Checking and Data Credibility for Social Content
  • Semantic energy data management
  • Automotive, e.g., electric vehicle charging, road side management, car insurance, communication interoperability
  • Distribution Logistics / Supply Chains Using Trustworthy Semantic Data
  • Data/Digital content /Multimedia marketplace, including social media
  • Decentralised Public Services & Common Goods
  • Other applications aligned with ONTOCHAIN objectives

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.



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:

Semantic Overlay Architecture

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.

IDunion Project Start

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.

Digital Immunization Passport Project Completion

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 […]

DAPSI: DIP Project Funding Extended into Phase 2

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 […]

Data Vault Deployment

Data Vault Deployment

Docker is required to install and run OwnYourData. The data vault is installed on the commandline and requires the following 5 docker images:

  • Database: postgres:9.6.4
  • Message Broker: rabbitmq:3-management
  • OwnYourData Data Vault: oydeu/oyd-pia2
  • Schedulder: oydeu/srv-scheduler
  • Running periodic tasks: oydeu/srv-worker

A script on Github is available for configuring and starting Docker containers. Run the following command in an empty directory to download and start the script:

bash <(wget -qO-

You have to provide the following four pieces of information:

  • IP address of the computer on which you want to run the data vault
  • Port number under which the data vault is to be reached
    (default value: 3000)
  • Gmail address for sending emails – necessary to create an account in the data vault and to send the weekly data summaries (eg:
  • the associated password to the Gmail address

The data vault is then available under the respective IP address and user accounts can be set up. The following blog posts describe how to use OwnYourData on your own NAS (such as Synology) and on an Asus VivoMini.

Managing Personal Data in Emergency Calls

In the DECTS project – funded by NGI TRUST Grant Agreement No. 825618 – OwnYourData and DEC112 implemented a Proof-of-Concept to demonstrate sharing personal data between an emergency caller and a control room.

Problem Description

The DEC112 App for deaf emergency chats allows users to store personal information (profile data) at the phone to be automatically shared with an operator in a control room when an emergency chat is initiated. But storing this profile data has a few disadvantages like inability to migrate this data when switching phones and also security concerns (anyone gaining access to this phone can read and edit the data). It therefore makes sense to also provide an option to store this emergency information securely in the cloud which in turn generates several challenges:

  • referencing and accessing emergency information in the cloud
  • migrating between cloud storage providers (GDPR Article 20 – Right to Data Portability)
  • guaranteeing secure storage of profile data

This blog posts describes the implementation of managing profile data in a Personal Data Store addressing the above-mentioned challenges.

Self Sovereign Identity

Decentralized Identifiers (DID) provide an elegant and self-determined way of managing access to personal data. Using cryptographic methods and blockchain technology a user can generate a DID (i.e., a unique token) that references a DID Document. In this document a service endpoint can be specified that provides a certain type of service. Since only the user is in possession of the cryptographic key to manage the DID Document it can be edited only by this user.

For the given use case of deaf emergency chats the DEC112 app automatically generates a DID at user registration and to reference an account in the OwnYourData Data Vault (source available here: The user has the option to choose between storing the data on the phone or in a Personal Data Store and when choosing Personal Data Store the respective DID is shown on the Profile page.


Shamir’s Secret Sharing

The OwnYourData Data Vault is a Personal Data Store that recently received the MyData Operator Status and is used as the default cloud storage for personal information associated with an DEC112 user account. Since it stores personal data End-to-End encrypted it was necessary to develop a solution to exchange this encrypted data with a control room. The component that manages data provisioning in case of an emergency chat is called PI2 (Personal Identifiable Information) – source code available here:

Upon creating an account in the OwnYourData Data Vault two key parts a created using the Shamir Secret Sharing scheme. One key part remains in the Data Vault while the other key part is sent to all participating PI2 services located in the respective control rooms. The profile data can only be decrypted when both key parts come together. Additionally, the Personal Data Stores logs any access to the encrypted profile data to guarantee complete documentation.

The data flow for accessing profile data during an emergency chat is displayed in the following sequence diagram.

The basic steps in providing personal information upon initiating an emergency chat include:

  1. The Viewer (client-side application used by the Call Taker) requests from PI2 additional information about the Emergency Call based on the DID delivered along the emergency chat.
  2. PI2 resolves the DID (i.e., retrieves the DID document) and gets the service endpoint of the PDS holding emergency information
  3. PDS sends encrypted emergency information together with one key part for decryption
  4. PI2 combines stored and provided key parts to decrypt emergency information and responds to Call Taker


This blog post described the infrastructure to share data in a secure and self-determined way. Users leverage capabilities of DIDs to manage a trusted service endpoint and use Shamir’s Secret Sharing scheme for a purpose-based data provisioning. A working prototype was implemented for the DEC112 project in Austria.


NGI DAPSI Funding for Digital Immunization Passport

Digital Immunization Passport has been selected as one of the brightest data portability projects in Europe

NGI Innovators

OwnYourData and the Human Colossus Foundation have been selected to take part in the Data Portability & Services Incubator (DAPSI), a 3-year EU funded project that empowers internet innovators to develop new solutions in the data portability field.

What is DAPSI?

The Data Portability and Services Incubator (DAPSI) is a EU funded project, under the European Commission’s Next Generation Internet (NGI) initiative, to empower top internet innovators to develop human-centric solutions, addressing the challenge of personal data portability on the internet, as foreseen under the GDPR and make it significantly easier for citizens to have any data which is stored with one service provider transmitted directly to another provider.

DAPSI will support top-notch projects through a 9-month incubation programme where experts in diverse fields will provide a successful working methodology, access to top infrastructure, training in business and data related topics, coaching, mentoring, and a vibrant ecosystem. On top of that, each DAPSI project can receive up to €150k equity-free funding.

Digital Immunization Passport (DIP) is taking part in DAPSI to create a state-of-the-art digital certificate of vaccination. Currently, vaccination and immunization information are spread over different organizations like labs and hospitals as well as pharmaceutical companies together with government agencies. A patient usually only has a paper certificate that provides vaccination treatments with often difficult to read handwritten additional information. In the proposed solution OwnYourData and Human Colossus Foundation will develop an end-to-end data flow that:

  • connects to various immunization information providers,
  • aggregates, harmonizes, and semantically annotates the data,
  • makes this data-set available in an open format accessible for Personal Data Stores (PDS), compliant to the MyData Operator guidelines,
  • provide a human-centric data management platform for health information,
  • allows to prove immunization status through Verifiable Credentials, and
  • packages selected health data for processing by 3rd parties together with a well-defined usage policy and a provenance trail.

The main focus of this project is on Data Interoperability & Compatibility through establishing interfaces between health industry and individuals as well as pushing forward on standardized interfaces for PDSs. Additionally, we address Data Transparency (Usage Policies and Data Provenance in Semantic Containers) and Security & Privacy (by applying blockchain technology and digital watermarking on data sharing).


How does it work?

In the two-phase supporting programme, the projects will develop advanced solutions in the Data Portability field. From September 2020 to February 2021 (Kick-Start phase) they will develop a solution related to a specific use case. The best projects will progress to the second phase (Booster) where the use cases will be fostered to evolve into solid projects to gain enough traction for deployment and get ready for the market.


Follow our journey through DAPSI!

Take a look at the DAPSI project portfolio to see more information about the selected innovators. The Digital Immunization Passport page is available here.

To read more about DAPSI, please visit the website: