The architecture of the Web 3.0 Data Space – as we see it now – has four major components, each of them crucial for the existence of the entire system:

• PODs: secure individual cloud servers storing all the data concerning people, companies, and objects in Linked Data format. PODs are accessible via Linked Data-enabled Solid protocol.
• Post-platforms: new generation platforms & applications using a fully distributed database of PODs for storage of users’ data.
• Register: a list of all PODs ensuring their discoverability and their proper indexation by semantic search engines.
• Security: Public Key Infrastructure (PKI) to provide all users with keys/certificates, cryptography, and protected data transmission protocols (including Solid).

PODs (Personal Online Datastores), individual secure servers for every person, company, or device, are the very basis of the Web 3.0 Data Space. They are based on the same principles as a traditional Web server, with the following difference:

• Web server was designed to be accessed and read by a human
• POD is designed to be accessed by a platform, therefore it requires machine-readable content (Linked Data-based) and machine-readable access protocols (Solid instead or on top of http)

We expect a large amount of PODs in a fully deployed Web 3.0 Data Space ecosystem, with the major share of PODs related to the IoT. According to our estimations, the total number of PODs may reach 1014 (a hundred trillion).

No CMS is necessary for PODs: actually, any platform may play a role of CMS.

PODs will be accessed by different users via thousands of platforms, therefore strong security is required. Every resource on a POD is controlled by an access list (ACL), defining which users may read or modify that resource. Access might be granted to specific users or groups of users. The control of ACL itself will be performed by the owner of the POD via any platform of their choice. Normally, the owner of a POD will not grant access to specific platforms, as platforms’ access to the Web 3.0 ecosystem will be controlled via a mechanism of platforms certification.

These POD servers can be hosted by any POD-hosting provider, with a mandatory automatic regular backup to several other virtual servers hosted by different providers, offering significant redundancy. In addition to this, many resources, especially dealing with user profile, will be tamper evident. A seamless migration of a POD to a different POD-provider with no vendor lock-in. E.g. no need to update any links to resources after such a migration, since we use a Persistent ID system.

Whether for social networking, messaging, selling things, ordering tickets, or getting digital services — all the data we produce and the data related to us is stored in one place we fully control.

It is important to mention that PODs will keep not only data we explicitly create, but also the auxiliary data, created about us by other people: likes, dislikes, ratings, reviews, and any other feedback about respective individuals, companies, and objects. Usually such data is associated with a social graph, which could be built and visualized by any specialized platform of user’s choice. Nowadays, such data is scattered across the multitude of platforms we deal with. In the Web 3.0 Data Space, platforms will write this data directly to your POD.

Same is true for other auxiliary data collected by smart devices (e.g. health or itinerary data recorded by smart watches): it will all be stored on the POD of the person concerned.

Hence, PODs will become an enormous storage of multiple types of data, including both personal and auxiliary data.

On top of that, public data from various authorities, municipalities, police, Cadastre, schools, or doctors will also be stored on PODs, and not kept in their respective systems. This data storage structure is one of the pillars of the Data Space.

The idea of PODs, using Linked Data to store data and Solid protocol to access them, fully belongs to Sir Tim Berners-Lee, the father of the Web. It is a great invention, and we mostly re-use his ideas in our Web 3.0 Data Space vision. But we have developed the idea of PODs further in 3 aspects:

• We want Post-Platforms to access PODs (Berners-Lee expected only in-browser apps to do it)
• We introduce a Register (similar to DNS) to make PODs discoverable for platforms
• We apply the principle of security-by-design, as most of Web 3.0 services will require ultimate level of security

The Web 3.0 Data Space we are building would hardly be possible without Linked Data. This format ensures data scalability, makes it machine-readable (which is essential for post-platforms to enable their interactions with PODs), and obviously enhances overall platforms interoperability.

People prefer free text, while machines best operate on fully structured data. Linked Data is a reasonable compromise: with very little semantic tagging we can allow arbitrary systems to reason about our data semantically.

As Linked Data will become common in numerous verticals, platforms will learn to use it quickly, as it will be the only way for them to stay in the market. This inter-platform language will evolve by itself, without centralized guidance, with some platforms introducing new jargon, and others adopting it.

While PODs are essentially “data keepers”, platforms are “data aggregators and service providers”. From the user perspective, Post-Platforms are exactly “good old platforms”. The only difference is that they keep all “their” data at PODs, sometimes even at billions of PODs.

In order to provide performance comparable to today’s platforms, post-platforms might be using internal databases for “caching” purposes, but not to store the “original” data.

Platforms will discover PODs via the Register or most probably via commercially available semantic search engines (or smart-registers).

Interoperability

The reference protocol for us is http, since it is ubiquitous and almost any existing device is capable of speaking it.

It is natural for Web 3.0 to use http/s between post-platforms and PODs as transport. Besides it, we will need to process semantic requests for Linked Data, and the most suitable protocol here is Solid, developed by Sir Tim Berners-Lee and his team. Yet we are not bound to use exactly Solid (or all functionalities of Solid), since there exist other alternatives as well. And finally, according to our strategy, we will need to implement “security by design”. These three “layers” represent our vision of interoperability between post-platforms and PODs.

It is extremely important for the idea of interoperability and for the future of the Web 3.0 Data Space in general, that all the protocols we use remain open W3C standards, otherwise it would become yet another proprietary system instead of Web 3.0.

The Web 3.0 Data Space model assumes interconnection between post-platforms and PODs, however:

• It does not assume interconnection between PODs (unlike the original Solid concept), since there is no need for “data to talk to data”
• It does not assume interconnection between post-platforms themselves (although IDS or Gaia-X see it as the only point of interaction in their version of Data Space), since post-platforms have to deal with data directly.

In a way, it is similar to the Web 1.0 architecture: a Web server interacts directly with a browser, and web servers or browsers are not interconnected amongst them.

In order to make this large-scale system fully operational, we will need a service to transform POD IDs into their IP addresses. The closest equivalent is DNS, which proves to be reliable and viable. In a similar way, the Register will be managed by an independent non-for-profit similar to ICANN.

The situation with “limited space” of IDs will certainly have to be avoided, as there will be an unlimited and free ID range. Following the DID standard from W3C means that these PODs will be easily referenced.

When fully implemented and accepted as an open W3C standard, this system will be able to substitute the existing DOI system.

Platforms (even the smallest ones) will need immediate access to PODs relevant for their business. As it will be difficult for platforms to deal with 10^14 PODs immediately, we expect semantic search engines to fill the gap.

Security is a crucial element of the Web 3.0 Data Space for obvious reasons:

• Individual PODs concentrate virtually all the data about a person or a company, and they become the only authoritative source of original data
• It is necessary to control who has access to a POD, to track their activities, to be able to roll them back, etc.
• The concept assumes that private PODs will keep elements of public and corporate data, which required even stricter risk-management policies and procedures
• Related services, like e-Reputation, e-money, e-voting, etc., will require the highest level of security and strong authenticity

With all these and similar requirements in mind, we clearly need a system that is global and which at the same time attains what we call a “total security” level.

We strongly believe that real security could be achieved only if started from the foundation, which means, in our case, that we need to apply secure-by-design principles and to design and deploy a powerful key management system.

Secure-by-design

All major digital systems built in the past decades – Internet, ftp, email, web, DNS – were designed without “secure-by-design” approach, as it was believed that “security will be added later on”. Which actually has never been done.

Secure-by-design architecture is a must and a major component of the entire system.

And any real security starts from key management.

Public Key management Infrastructure (PKI)

The weakest point of modern security is not the algorithms and protocols, but the keys. One of the best things to manage them is the Public Key Infrastructure, a hierarchical network of notaries who certify users’ open keys.

Currently, full-scale PKIs are used mostly in corporate and bank environment, but nobody dared to deploy a global one. The only known global PKI system is the one that supports the https protocol of secure connections between browsers and web servers. But still, this is a one-way security, as it protects (with a key/certificate) only the web server, and web servers, in their turn, cannot fully trust their users’ identities. This issue is addressed in a very inconvenient way by using logins/passwords, phone numbers, or emails to authenticate users.

We suggest a very simple solution: a global PKI, which provides keys/certificates both to servers and to users. No more need for logins/passwords.

Let’s emphasize that the strong authentication system can still provide a desired level of anonymity (so-called zero-knowledge proof) when needed, as described in the W3C standard for Verifiable Credentials (VC).

Private keys

The desired level of security of the Web 3.0 Data Space requires hardware based private keys, e.g. on USB-fobs or Mobile IDs. Such devices are well protected from leaking the key out.

Security of PODs

Essentially, PODs are protected cloud servers.

• They will be controlled only by their owners
• They will have hot spares in the clouds managed by competitors to ensure reliability
• They will have snapshots to ensure roll back options when required
• They will allow the owner to control ACLs to provide access to certain people, groups, or platforms
• They will keep the log file with all actions of all users

Security of Post-Platforms

Access control (ACL) is introduced between users and PODs, and not between platforms and PODs. E.g. Bob can use any platform of his choice as long as Alice included him into her Access list.

We can derive the only requirement for platforms here: they should meet certain qualification. Just like in other industries, such qualifications can be granted by industrial associations, which are usually non-for-profit.

In our case eventually, every platform will also accumulate its e-Reputation (kept on its POD), which will eventually guarantee its “service quality”: users might prefer to use platforms with higher e-Reputation.

Evolution of security

The “total security” we describe is a rather ambitious project. We can deploy it only in stages, starting from much lighter versions for certain industrial applications. Still, it will be a “secure by design” approach with appropriate key management at the core.