Datarella GmbH, a Web3 company builder, is joining forces with deltaDAO AG, a Web3 engineering and integration company, to expand the open data economy in the mobility and identity sectors. Both companies leverage their extensive experience in creating Web3 solutions for real-world use cases. The partners aim to allow corporate and individual users to monetize data while preserving their privacy. The first project is inspired by the partners’ collaboration in moveID, a Gaia-X 4 Future Mobility project. It will allow the monetization of mobility service provider data.
Datarella and deltaDAO will use their enterprise Web3 tools and consumer apps to jointly build solutions for the monetization of data featuring Fetch.AI and Ocean Protocol technologies. This combined tech stack serves as the foundational underlying protocol for digital business transformation with converging technologies, s.a. AI, and autonomous machines. Given the natural synergies between Datarella and deltaDAO, this cooperation will drive enterprise adoption across the partners’ client bases.
For Datarella, the purpose of technology is to increase the quality of living, by supporting human beings in professional activities and private lifestyles. The growing complexity and diversity of our ecosystem require technological infrastructures that facilitate collaboration and cooperation. By creating Web3 solutions for a global user base, Datarella illustrates the real-world benefits of its Web3 technology stack, and with deltaDAO, we will show how individual and professional users can turn the table and monetize their data, instead of “being the product”, .
Michael Reuter, CEO of Datarella
deltaDAO has become a trusted advisor for building sovereign, privacy-preserving, and secure data economy solutions. We seek to give freedom of choice and control back to data owners. As a DAO we create a new kind of data economy that is owned by no one – and open to everyone. Our partnership with Datarella will lead to many impactful real-world use cases and is a great example of how two companies can leverage each other’s strengths and experience to create real-world solutions for both individual and professional users alike. We are excited about building towards a decentralized data economy together with Datarella!
Frederic Schwill, Co–Founder of deltaDAO
About Datarella
Datarella GmbH is a Web3 company builder. Leveraging its technology stack of Blockchains, Self-Sovereign Identity SSI, Autonomous Agents, and Artificial Intelligence AI, as the tech hub for Web3 projects and companies like MOBIX, MOBIX family, IMMOBIX, or NOMIX, Datarella creates applications with real-world benefits. The Munich-based company was founded in 2013. With its decentralized teams in Munich, Gdansk (Poland), and Skopje (North Macedonia), Datarella develops bespoke Web3 innovations for their partners and clients, s.a. United Nations, World Food Programme, UKAid, ESA, Siemens, BMW, BOSCH, and Airbus.
About deltaDAO
deltaDAO AG is a software development, integration, and consulting company based in Hamburg, Germany. Its focus is to enable a transparent, secure, and decentralized data economy in which enterprises, SMEs, and public institutions can keep full technical control over their private data. As specialists in distributed ledger technologies (DLT) we are engaged in Gaia-X and built the first Minimal Viable Gaia-X (https://minimal-gaia-x.eu/) in 2021, based on open-source software and Web3 technology.
As one of the selected parties in the current eSSIF program, Datarella aims to bring Anoncreds based on CL-Signatures to the Aries Framework Go. In this blogpost, we provide a progress report on the Aries Bridge from the project we are working on in the eSSIF-Lab and where we are heading next.
There are currently two major types of Verifiable Credentials used in the SSI world that implement different cryptography schemes and have different capabilities. However, both are perfectly fine to implement working SSI use cases.
The first type is based on the “Camenisch-Lysyanskaya ZKP” signature scheme, or short CL-Signatures, to issue so-called Anoncreds. It is used in SSI projects that implement Hyperledger Indy, a DLT with an SDK that was created specifically for SSI use cases and with support of the Aries Protocol. The popular Aries Cloud Agent Python is implementing these kinds of Verifiable Credentials and therefore a lot of existing SSI use cases are using Anoncreds.
The second type are JSON-LD credentials which is recommended as a standard by the W3C. It comes from an ledger independent approach and relies more on semantics which allow for a broader ecosystem interoperability. This approach is preferred among the Aries Framework Go ecosystem.
One major problem is that these two types of Verifiable Credentials are not compatible with each other as they are using different cryptography determined by the ecosystem they are residing in. Therefore, Datarella aims to make Anoncreds available to the Aries Framework Go to get the best of both worlds. This allows for deploying agents on non-mobile edge devices while being compatible with solutions built on the Aries Cloud Agent Python or Hyperledger Indy, respectively.
We decided to write a wrapper of the indy-credx library in Go. This allows us to call the indy-credx functions for credential management from a Go environment, such as a vehicle or a mobile device. Our pull request was successfully merged in the shared rust libraries and is now openly accessible by others. However, this was just the first step. In the next step, we will integrate the wrapper with the Aries Framework Go to simplify the integration from that side.
Stay tuned for when we are giving a progress report on the Aries Bridge again in our News section; e.g. leveraging it for the mobility space in our moveID Gaia-X project.
This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the eSSIF-Lab Project funded under grant agreement No 871932.
With Datarella, we have been building software, tools, and applications for Web3 since 2015. Our first truly global project has been the Building Blocks application which enables users to securely pay with their smartphones in refugee camps.
We‘ve developed Track & Trust, a tracking solution for humanitarian aid logistics that leverages satellite communication. In the mobility sector, we have created SSI apps and smart parking solutions to enable secure P2P communications, streamline traffic flows, and minimize CO2 emissions. With 16 other companies, we’re part of Gaia-X consortium moveID that will create the decentralized digital infrastructure for mobility in Europe. And much more! And, in 2020, we decided to leverage our tech stack and create the Datarella Web3 Company Builder Model.
RAAY Real Estate
In 2020, we have launched RAAY Real Estate (RAAY RE) as our first standalone project, together with two partners from the real estate industry. Our RAAY RE joint venture with Hammer AG and Wertgrund Immobilien AG was the first to tokenize a commercial property, fully licensed by German regulator BaFin – Connex Coin was a breakthrough! RAAY RE will become the legal framework of our future IMMOBIX project and token.
MOBIX Marketplace
In 2021, we launched our micromobility marketplace MOBIX. By using the MOBIX app, more than 350,000 daily active users in over 120 countries are earning MOBIX Miles while riding eco-friendly vehicles, such as scooters, bikes, eBikes, eMopeds, or cargo bikes. By incentivizing users to swap their combustion engines with zero-emission transportation, MOBIX helps to decrease CO2 emissions and to make cities more liveable. In the meantime, MOBIX has evolved into the MOBIX Marketplace GmbH, a Munich-based company owned by Datarella, and Fetch.ai.
MOBIX family
The latest brainchild of Datarella’s Web3 Company Builder Model is MOBIX family – a decentralized gig economy network. MOBIX family is the first project in the Company Builder Model that will be driven with the support of an external team. Whereas RAAY RE and MOBIX have been built by internal Datarella resources, a young team of aspiring entrepreneurs from the Technical University of Munich (TUM) has taken care of the Family’s first steps. The team has presented the first MOBiX family MVP during START Ideasprint 2022, a 4-day hackathon based out of Munich.
NOMIX
In 2023, the next project – NOMIX – will launch its BIOCLOCK app. Leveraging the same tech stack as other Datarella Web3 companies, NOMIX will help users around the world maximize their healthspans, i.e. living longer while staying healthy!
We at Datarella are very happy to see more and more teams using our Web3 tools and applications, and creating new ventures! Are you interested in joining an existing Web3 team or do you want to pitch your own idea? Do you want to become part of the Web3 world but prefer to participate from the sideline, you might be interested in owning DREX, our Datarella token which entitles the holder to receive tokens of Web3 projects. In either case, please contact us!
In this blog post, we look at the potential of service automation through autonomous economic agents in Blockchain-based systems. Datarella’s partner Fetch.ai has made it their mission to combine intelligent agents with blockchain technology in several use cases. Deep Parking is one of them, and using a specific example from MOBIX here you can get a feel for the potential of autonomous agents.
The path to the fourth industrial age is being paved by the interplay of Big Data-driven automation, robotics, IoT and Distributed Ledger Technologies, aka Blockchain. Given the increasing amount of data, and the number of digital services that go hand in hand with this progress, the need to automate them is also growing. Users should be relieved of unnecessary work and offered optimal results.
Agents take on the role of autonomously performing tasks on behalf of their clients (individuals or objects). For this purpose, they can also interact with each other. Intelligent agents can make complex decisions by using ML, i.e. AI-powered algorithms, based on large amounts of data.
A blockchain, with its data supply, offers a particularly favourable environment for intelligent agents. The data of a blockchain are permanently available and are logically related to each other. Decentralisation can offer robustness (no single point of failure) and lower transaction costs. Agents can assume a fully autonomous identity on a blockchain through private keys. They can use it to authenticate themselves and communicate their suitability for certain tasks. Agents can use shared protocols (possibly through smart contracts) to coordinate, collaborate efficiently, e.g. by distributing complex tasks among themselves. They can negotiate and make distributed decisions (even though voting processes use their blockchain). Tasks, goals or motives of agents can be recorded in the blockchain and economic incentives can be set for optimal task performance.
With regard to the IoT, a blockchain (as a single point of truth) can integrate various sub-systems, s.a. smart household appliances, smart buildings, smart districts and smart cities, and create added value for all agents participating in the network. Fetch.ai is an example of how intelligent agents can realize automated services based on blockchain technology.
Among the use cases of Fetch.ai, we would like to highlight agents for mobility services – traffic sign agents, parking agents for Deep Parking, agents for eMobility, agents for trains and stations that could even form a decentralised train network. In the process, increasingly intelligent autonomous agents interact on behalf of people or infrastructure, searching for each other, negotiating with each other in the interest of offering their users optimal solutions. In such a case, an autonomous agent of a car could, on behalf of its owner, seek and negotiate with agents working on behalf of parking lots to navigate the car and its owner to a quick and cheap place to park. With Deep Parking at the IAA in Munich 2021, the potential of agents for such use cases becomes clear.
There it was demonstrated how agents negotiate their resources on behalf of vehicles, their owners and the infrastructure to find an optimal solution for everyone without further efforts for the users. The following graphics show an excerpt from the exemplary communication between the agents involved.
In this case, a user named Jane is looking for available parking space in the city centre. Without Jane having to do this herself, the agent in her car (My Agent (Car)) looks for another agent who offers a parking space via a specific (agent-)network (SOEF). Using Blockchain technology, agents handle authentication, price negotiation, reservation and even payment, autonomously according to their client’s preferences. When Jane approaches the parking lot, access is automatically granted to her car without further ado.
As shown, the scope of tasks autonomous agents can perform and the added value they can contribute is without limits. So, by using autonomous agents, the potential of Blockchain technology can be leveraged for all use cases where handling of huge amounts of data in real-time or near-time is needed.
Datarella is offering its customers state-of-the-art Self-Sovereign Identity infrastructure with its SSI Wallet for innovative identity management. It can be integrated into new or existing ecosystems and provide fundamental decentralized identity infrastructure for users to authenticate, issue and receive Verifiable Credentials or transfer data. This allows for many innovative use cases like credential-based access management, automatic credential verification or trusted data transfer.
The Wallet
Having full control over an own digital identity is one of the fundamental principles for Self-Sovereign Identities. This includes that private keys and verifiable credentials are not stored on a centralized exchange or platform, but on the user’s very own devices in a decentralized manner. From this device, the user can issue or receive credentials and authenticate themselves by connecting with other SSI agents.
Like in the physical world where an identity is represented by an ID document which is often kept in a physical wallet, digital private keys and verifiable credentials are stored in a digital wallet. From here, the user can decide with whom the user interacts and shares information from its wallet. The user can ensure that private information is stored only on authorized devices and not in centralized databases which reduces the risk of data breaches tremendously. A wallet can have various forms, a browser extension, a hardware wallet or an entire app like Datarella’s SSI Wallet.
Technology
The SSI Wallet is meant to be deployed in ecosystems that allow users to interact with each other, with SSI compatible websites and IoT edge devices like micromobility vehicles. This is enabled by the Aries Framework Go, which supports a broad variety of edge- and cloud environments.
The wallet further provides a high level of privacy as it natively supports did:peer methods which creates pairwise pseudonymous DIDs for each individual connection and therefore avoids correlation by design. Even though did:peer does not require a ledger, the Aries-Framework Go supports public DID methods like did:web or DIF’s Sidetree protocol. It further allows selective disclosure of credentials thanks to its support for BBS+ signatures. The SSI wallet is therefore perfectly suited for public adoption as well.
It will soon also contain SDKR – a decentralized key backup and recovery mechanism that allows you to backup and recover your secrets with only your official eID. No need to remember passwords or the location of your backups thanks to eIDAS and decentralized and opaque storage capabilities from StorJ.
Conclusion
With our SSI Wallet, we are confident to demonstrate the benefits of Self-Sovereign Identity perfectly in a privacy-preserving and intuitive manner. By using the Aries-Framework Go, we can ensure that it works on web applications and mobile solutions as well as on proprietary IoT devices either without a ledger entirely (only P2P) or by using did:web or the Sidetree protocol.
We are happy to announce that Datarella is now an Associate Partner of the IDunion consortium. As an established blockchain solution provider Datarella adds expertise in blockchain development, system design and identity management.
IDunion develops a basic infrastructure for the verification of identity data. For this purpose, a distributed database will be jointly operated by a European cooperative. The network will be set up and managed by various actors consisting of private companies, associations, cooperatives, government institutions, educational institutions and other legal entities.
IDunion’s infrastructure is based on open standards and open source technology for Self-Sovereign Identity (SSI) and is particularly characterized by data economy and transparency. The solution gives users the opportunity to manage their identity information themselves and to decide when and with whom they want to share it.
Today, the long-awaited Covid-19 tracing app will be released in Germany, which should help to detect infection chains and warn potentially infected people that they were in contact with someone infected with the virus at some point recently. The decentralized approach of the app raises some questions: Are there parallels to the concept of Self-Sovereign Identity? And if so, are we witnessing the first broadly useable application for SSI in Germany? I will face these questions in this blog post.
Even though the app is already delayed, as it was promised to be released almost two months earlier, it still comes at the right time since life in Germany is getting back to normal again. The app was released in Germany so long after other countries due to many reasons, one of them being privacy. There should be no possibility that this app holds any form of personal information for anything beyond its actual purpose. In fact, the developed app is overall pretty solid. It respects the users’ privacy, it is simple to use, and no central institution has too much control over the data. Let’s analyze some criteria from an SSI point of view to determine if it is a self-sovereign identity:
Control
To begin with, we need to look at who has control over the identifiers. These are designed to be self-creating on the user’s device and frequently automatically changing. The user doesn’t have to create and register them manually. In fact, the user has no control over how the identifiers are being created or exchanged with others. Therefore, randomly created ids violate the principle of control over the identifier since the user does not influence it.
Forming of Connections
As the next criteria, I want to take a look at how connections are established. In the SSI ecosystem, connections with others are formed via the DID Auth protocol, which verifies that the user holds valid keys for a DID. In the tracing app, this is done via Bluetooth. The device automatically recognizes other devices in Bluetooth-range and stores their ID, timestamp, and signal-strength for 14 days. If an infected person was later identified, all the IDs would be sent to a central server from which the user’s devices are frequently polling. If the IDs match up, the app warns the user that he or she might be infected. This is also contrary to an SSI approach were connections are formed with explicit consent, and exists for as long as one party terminates the connection.
Even though more criteria help to determine if the tracing app is a Self-Sovereign Identity, it is already clear that it is not a Self-Sovereign Identity, even if it is much closer than a centralized approach. However, it would be possible to align it more with SSI principles.
Tracing App with Blockchain Integration?
Let’s say the user downloads an app that has the functionality of creating compatible key pairs for an underlying blockchain or DLT. These would also not be human-readable and would further allow interactions with the underlying blockchain. If a person was diagnosed with Covid-19, the device could perform a transaction to the ledger and its IDs would be stored in a central revocation registry that the devices pull from. Therefore, there would be no need for a centralized server that is run by a single institution. Using a blockchain here would bring some benefits as well as it could work across borders and probably for less than what SAP and T-Systems, a subsidiary from the Deutsche Telekom, charge.
In short, I hope that this app has the most success and that people will use it to combat this pandemic and end it as soon as possible. I further hope that decentralized approaches, where the privacy of the user is the main priority, are becoming more popular and allows people to see that we don’t always have to provide sensitive personal information to anyone that offers an online service. And last but not least, I hope to see more people are aware of the benefits of Self-Sovereign Identity so that its public adoption is achieved earlier than expected. The concept of this app is a step in the right direction, and I hope there will be more to come!
Do you want to know more about Self-Sovereign Identity? Read my series, watch a webinar I held recently, or contact me!
Last week, Martin Schäffner gave an introduction to blockchain-enabled Self-Sovereign Identity at the Crypto and Blockchain Meetup bdvb HG Bayreuth. Did you miss it? No problem! Re-watch his webinar on YouTube (link below).
Self-Sovereign Identity is a trending topic in the blockchain-scene. It aims to take away dependency on classic online identity providers such as Google, Facebook, or common online services that require to create an account to use it. This is achieved by letting the user create and manage its own identifiers through independently creating decentralized identifiers (DID), that don’t require a centralized institution. Information can be asserted to these identifiers by issuing Verifiable Credentials to the identity owner, which can then be presented with third parties in a privacy-preserving and fully automated manner.
In the webinar, Martin speaks about the differences between conventional online- and self-sovereign identities. He further introduces key elements in relation to Self-Sovereign Identity and reflects an overall picture of the SSI architecture and process flows for issuing and presenting verifiable credentials. He also gives an outlook on which use cases can benefit from implementing SSI.
Are you hooked? Watch it here again on YouTube:
For more content about Self-Sovereign Identity, I can recommend reading my series about Self-Sovereign Identity, starting with the first part.
Do you have questions about SSI or just want to leave feedback? Contact me!
Last week we started a series of articles for an introduction to Self-Sovereign Identity components. In the first article, we have taken a look at some of the fundamental elements of SSI – Decentralized Identifiers (DIDs), their corresponding DID Documents and Verifiable Credentials. We now understand that DIDs are the digital and sovereign representation of an identity, that is further described in the DID Document and from and to which we can issue Verifiable Credentials. Part 2 of the series, we face the question of how DID Documents are technically associated with a DID and how we can authenticate using DIDs.
If you want to know what SSI is in general and how it could affect our online environment and behavior, take a look at the introduction article to SSI.
DID Resolution
DID resolution describes the process of getting from the DID to its associated DID Document. It is the basis for creating connections, initiating interactions, and proving ownership via DID Auth (see below). DIDs should be globally resolvable, allowing others to look up the DID document, for example, to start an interaction. Since every DID method works somehow differently and has different ways of creating and storing a DID document, resolving them works differently for each DID method.
There are three main ways of how DID Methods, which define how to create a DID, and manage DID Documents. They could either be publicly stored somewhere and referenced in the transaction itself – like in Bitcoin Reference (did:btcr:) or generated by gathering events of a transaction to an authorized account – like in uPort’s ETHR DID Method (did:ethr:). The third way is to automatically generate the DID Document by the ledger itself like in Sovrin (did:sov:).
To create an interoperable SSI ecosystem, it would be useful to dynamically resolve the DIDs of any DID method. By doing so, DIDs from different blockchains could interact with each other. One system that does this is the “Universal Resolver”, which is illustrated in the following figure. Here, Webservices, Apps, or other services can resolve any DID Document that has a driver implemented in the Universal Resolver.
Model of the Universal Resolver
DID Auth
Cryptographically authenticating an identity owner, is a central goal in the SSI ecosystem. To establish trusted connections, proving control over a specific DID as long as the DID exists. In SSI, this specification is called DID Auth and relies on a challenge-response authentication protocol where the identity owner signs the response to authenticate. DID Auth uses the authorized public keys listed in the DID Document for authentication.
The challenge-response cycle can be implemented with multiple protocols. One of the preferred ones is using a JSON Web Token. However, it also works with other protocols such as the TLS handshake protocol, OpenID Connect, or even HTTP.
The following figure shows a simplified process of DID Auth.
Source: Introduction to DID Auth (Sabadello, et al.)
At first, the Web-Site of a relying party displays a QR on the Identity Owner’s Web browser that contains the DID-Auth Challenge. In the next step, the Identity Owner scans the QR Code and sends a DID-Auth Response with the signature of the Identity Owner’s private key to the Relying Party’s web server. Based on this private key signature, the creation of an proof signature indicates control over a DID. The web server receives the response and can validate that the identity owner controls the DID by resolving the DID document and validate the public key. After the successful authentication, the relying party’s web page polls this information and displays its content. For a more detailed description of DID Auth, I recommend taking a look at this document.
Conclusion
In this second article about the introduction to Self-Sovereign Identity components, we got to know DID Resolution and DID Auth.
To summarize, DID Resolution describes the process of getting from a DID to a DID Document. This process is essential as the DID Document contains important information about the DID, such as authorized public keys or service endpoints. This information is crucial to start an interaction like proving ownership or control over a DID, which describes the process of DID Auth. By implementing a challenge-response cycle, an identity owner can prove ownership or control over a DID and therefore creates trust between both parties. It’s worth mentioning that, in this case, only requires these two parties, and no additional identity provider needs to be involved. As a result, DID Auth creates a trusted fundament for further interactions, such as issuing credentials or other data exchange.
In the third part of this series, we will take a more in-depth look at Verifiable Credentials. How can these be issued, how can they be trusted, or how can they be managed will be questions we are going to face and answer.
If you have any questions about SSI or want to leave feedback, feel free to contact me.
