This paper identifies the opportunities for the Solid environment in light of the new EU mandatory data sharing obligations under the Data Act. It also outlines several misalignments of current Solid specifications and specific EU legal requirements under the GDPR and the Data Act. Reflections are put forth on the current third party pod providers identified on the Solid Website. The legal framework for data sharing in the European Union (EU) is experiencing a profound transformation. The EU Data Protection Regulation (GDPR) mandates the portability of personal data (art. 20 GDPR) in some limited conditions, but only if technically feasible. Meanwhile, the Regulation on the Free Flow of Non Personal Data (FFNPDR) sets a voluntary framework for the sharing of non-personal data. Neither of these instruments achieved the desired increase in data availability in the EU market. Therefore, the EU's current strategy for data pursues a much more compulsory approach. Mandatory (also called statutory) data sharing includes all the circumstances that trigger the compulsory access (reading and/or transfer) of data. The recently adopted Data Act (DA) sets a general framework for the applicable conditions under mandatory data sharing (Ch. 3 & 4 DA) and mandates data sharing in two specific contexts: connected devices (Ch. 2 DA), and data processing services (Ch. 6 DA). The Solid environment can offer a technical solution that operationalizes these data sharing obligations. This paper pursues two goals: 1) to identify the opportunities for the Solid environment to operationalize the statutory data sharing obligations contained in the DA, and 2) to outline the shortcomings or misalignments of current Solid specifications and the EU statutory data sharing requirements. In its conclusion, this paper reflects on the Third Party Solid Providers (the Pod Providers) currently available on the Solid Website.
Solid constitutes an environment built through technical specifications facilitating a
decentralized web in which users have control of their data, stored in pods. These are
defined as “secure web servers for data” [
Empirical research shows that companies do not have a distinguishable incentive to
transfer the data they hold [
The triggering circumstance for this mandatory data sharing is the presence of a connected product or related service (Ch. 2 DA). These belong to the increasingly popular world of the IoT. In the context of the IoT, product data is the “data, generated by the use of a connected product, that the manufacturer designed to be retrievable” (art 2.15 DA), and related service data is any recorded “data representing the digitization of user actions or events related to the connected product […] generated during the provision of a related service” (art 2.16 DA). These terms are grouped as ‘readily available data’ when they are or can be retrieved “without disproportionate effort going beyond a simple operation” (art 2.17 DA). Figure 1 below exemplifies the data flow. The individual using the given connected product or related service has the right to receive or access many of these IoT data points.
The individual can also choose to transfer this data from one business to a third party (art 5 DA), i.e., a Solid App. In this context, the Pod Provider can facilitate a more granular decision for the individual to specify the data types that should be transferred. The DA states that this transfer needs to be conducted (1) without undue delay, (2) free of charge to the user, and (3) where relevant and technically feasible, continuously and in real-time. The data received by Business B must be of the same quality as the data collected by Business A and have an easy-to-use, secure, comprehensive, structured, commonly used, and machinereadable format (art 5.1 DA). These obligations can be incorporated within the Solid specifications (Figure 2). This way, all these obligations are met by any apps within the Solid ecosystem.
Moreover, the granular decision-making by the individual in terms of which data is shared creates a clearer understanding of the data flow. This clarity can simplify the identification of unlawful data processing by Business B (art 6 DA), which would also benefit Business A and could act as an incentive for the Solid environment to flourish.
The DA also sets several obligations for DPSPs to facilitate switching among them (art 23 DA). DPSPs are entities delivering digital services to users, i.e. computing capabilities, such as the manipulation, storage, structuring, organizing, and analyzing of data (art 2.8 DA). Pod Providers are a type of DPSPs. According to the Solid technical specifications, Solid Pod Providers already meet the interoperability requirements to facilitate switching under the DA (art 30). Thus, if non-Solid DPSPs adopt Solid specifications, they would comply, by definition, with this DA obligation. However, the Solid environment sets much more stringent criteria for interoperability than mandatory DA conditions. For example, under the DA, interoperability is compulsory only for the same type of DPSPs (not all), and only if technically feasible (art 35 DA). Therefore, it is unlikely that businesses that want to disincentivize customers from using their data across different DPSPs will adopt Solid specifications. However, the gradual withdrawal of permitted switching charges, no longer allowed from 12 January 2027 (art 29 DA), may make Solid increasingly appealing over time for DPSPs, as Solid DPSPs would not need to devise new costly technical solutions to facilitate switching. Moreover, in enabling the simultaneous use of more than one DPSP (art 34 DA), the Solid architecture can be advantageous (Figure 3).
The DA sets forth the interoperability requirements for participants in Common European Data Spaces (art 33 DA). A solid environment can enable companies to meet these interoperability requirements. However, this will require aligning the Solid specification to the requirements currently being developed for the different data spaces. The Solid pod architecture may be particularly useful for creating “cross-sectoral interoperable frameworks” (art 33.1 DA) to preserve the individual’s choice in deciding which data can be used for what.
The Solid Protocol indicates that Solid pursues individuals to “maintain their autonomy,
control their data and privacy, and choose applications and services to fulfil their needs”
[
Solid pursues a decentralized web in which the individual controls their data. However, the
technical solution in which Solid sets a user-centric control may cause issues when applying
EU law. In the Solid environment, individuals choose the data they want to store in their
pods and the access, use or write permissions they grant to other entities, such as Solid apps.
Given the technical design of the Solid pod, Pod Providers and Solid Apps are likely to be
considered data controllers. Pods are linked to an individual’s WebID, one’s “identity in the
Solid ecosystem” [
The DA creates legal grounds prohibiting specific instances of data sharing. This is the case for gatekeepers, who cannot benefit from the DA, i.e. they cannot be data recipients (art 5.3 DA). Businesses designated as gatekeepers under the Digital Markets Act (DMA) have had, during a relevant period and for a foreseeable duration, a “significant impact on the internal market” and behave as a gateway for other businesses to carry out their operations (art 3.1.a DMA). This prohibition is unconditional and explicit. Therefore, the Solid technical specifications may need to be adapted to prevent gatekeepers from receiving or requesting data. Otherwise, the Solid specification would favor the breach of EU law.
Moreover, the DA sets a wide array of reasonable and nondiscriminatory terms and conditions that all mandatory data sharing must fulfil, as well as several assurances regarding liability and remedies (art 8 DA). These are aspects that the Solid specifications may need to incorporate to position themselves as abiding by EU law. The same can be said about the technical protection measures preventing unauthorized use or disclosure of the individual’s data set by the DA (art. 11).
The decentralized nature of the Solid environment may make the adaptation of Solid specifications for EU legal compliance difficult because of the lack of a central authority. This is especially true given the different data spaces that are being created in the EU, for which diverging legal or technical requirements may be adopted. To this end, different Solid branches may need to be created; that is, different Solid specifications, interoperable among one another, depending on the legal bases for the specific type of data sharing.
Nevertheless, few Pod Provider options currently exist for individuals. According to the
Solid Website, most Pod Providers for individuals are presently prototypes. Inrupt pods are
not usable, with its privacy policy stating that their pods are intended for research and that
users shall not use them to store personal data [
In 2021, Solid was described as being “in its infancy” [