You are currently viewing a new version of our website. To view the old version click .
MDPIMDPI
Search all articles
Information
Download PDF
  • Article
  • Open Access

24 November 2023

Is Automated Consent in Solid GDPR-Compliant? An Approach for Obtaining Valid Consent with the Solid Protocol

and
1
Security, Technology and ePrivacy Group (STeP), University of Groningen, 9712 GH Groningen, The Netherlands
2
Ontology Engineering Group (OEG), Universidad Politécnica de Madrid, 28040 Madrid, Spain
*
Author to whom correspondence should be addressed.
†
These authors contributed equally to this work.
Information2023, 14(12), 631;https://doi.org/10.3390/info14120631
This article belongs to the Special Issue Addressing Privacy and Data Protection in New Technological Trends
Version Notes
Order Reprints
Review Reports

Abstract

Personal Information Management Systems (PIMS) are acquiring a prominent role in the data economy by promoting services that help individuals to have more control over the processing of their personal data, in line with the European data protection laws. One of the highlighted solutions in this area is Solid, a new protocol that is decentralizing the storage of data, through the usage of interoperable web standards and semantic vocabularies, to empower its users to have more control over the processing of data by agents and applications. However, to fulfill this vision and gather widespread adoption, Solid needs to be aligned with the law governing the processing of personal data in Europe, the main piece of legislation being the General Data Protection Regulation (GDPR). To assist with this process, we analyze the current efforts to introduce a policy layer in the Solid ecosystem, in particular, related to the challenge of obtaining consent for processing personal data, focusing on the GDPR. Furthermore, we investigate if, in the context of using personal data for biomedical research, consent can be expressed in advance, and discuss the conditions for valid consent and how it can be obtained in this decentralized setting, namely through the matching of privacy preferences, set by the user, with requests for data and whether this can signify informed consent. Finally, we discuss the technical challenges of an implementation that caters to the previously identified legal requirements.

1. Introduction

The General Data Protection Regulation (GDPR) [1] has become the gold standard in the European Union (EU) and its effects are being globally felt in Asia, Latin America and Africa [2].
The purpose of the GDPR is twofold: on the one hand, it protects individuals in what concerns their human rights and, on the other hand, it enables the free flow of personal data (Article 1 GDPR). The EU expressed a vision that encompasses the creation of a single European market for data, where access to personal and non-personal data from across the world is secure and can be used by an ecosystem of companies, governments, and individuals to provide high-quality data-driven products and services for its citizens while ensuring that “EU law can be enforced effectively” and data subjects are still in control of what happens to their personal data [3].
In addition to the GDPR, novel data-related legislation with new data governance schemes, such as the Data Governance Act (DGA) [4], is being brought forward by the EU to build an infrastructure for data-sharing and to improve citizens’ trust. In particular, trust has been proven as an important factor that positively influences the perceived usefulness and ease of use of digital personal datastores [5] in data-handling services and allow them to share their sensitive data for the ‘public good’.
However, this has not come without challenges in its interpretation and enforcement. Complex data flows where multiple parties govern the usage, storage, and collection of personal data for both distinct or shared purposes pose several challenges in elaborating privacy policies and complying with the information requirements [6]. The allocation of rights and obligations concerning the processing of personal data is structured around different roles, the main being data controllers, data processors, and data subjects. Among other obligations, data controllers (the natural or legal person who determines the purposes and means of the processing of personal data) must document and declare a lawful and transparent purpose to justify the processing of personal data so that the data subjects (the people whose data are processed) can make an informed decision when it comes to the usage of their personal data. Furthermore, data controllers also have an obligation to provide information to the data subjects, as according to Articles 12 [1], said information must be presented in a concise, transparent, intelligible, and easily accessible form, using clear and plain language and this is not easy to assess and implement in reality.
Compliance with transparency obligations can be dealt with by providing lengthy, complex, ungraspable privacy notices, which place a significant burden on the data subjects [7,8]. Although the necessary elements required by the law are provided, and data subjects are offered the possibility to be informed, this involves a nearly impossible exercise: to understand the myriad of terms and conditions of all the services and applications that are used these days, from smartphone applications to social media websites and personalized streaming of digital content. Thus, the information provided to data subjects fails to be an efficient tool for data subjects to monitor how their data are used or how their rights can be exercised [9].
One mode that is being largely discussed these days is personal data sovereignty, which presents a radical change in the paradigm of data-sharing. In this new governance model, access to data is decentralized—data subjects assume direct control over the usage and sharing of their data, a solution that promises to balance the power relationship between web users and digital platforms by promoting the development of digital services focused on users’ needs [10,11,12].
In this context, the emergence of personal data spaces managed through Personal Information Management Systems (PIMS) is already being envisioned by the European Data Protection Supervisor (EDPS) as a mechanism to enable personal data sovereignty where “Individuals, service providers and applications would need to authenticate to access a personal storage centre” and individuals can “customize what categories of data they want to share and with whom” while keeping a track of “who has had access to their digital behaviour” and enabling data portability and interoperability [13]. Furthermore, these new user-managed systems represent the next step towards the matching of privacy terms between data subjects and data controllers and can actually play an important role in facilitating the exercise of data subjects’ rights, including the rights of access, erasure, and data portability or the right to withdraw consent [14]. In this context, a set of different PIMS initiatives has been gaining prominence and adoption in the last few years, including the MyDex Community Interest Company (https://mydex.org/, accessed on 25 October 2023)—a company focused on providing portable and interoperable identity services [15], the Hub of All Things (https://www.hubofallthings.com/, accessed on 25 October 2023)—an ecosystem focused on providing contract-based access to self-sovereign data with technology implemented by Dataswyft (https://dataswyft.com/, accessed on 25 October 2023), Meeco (https://www.meeco.me/, accessed on 25 October 2023)—a company offering personal data storage and verifiable credential services [16], and the Solid project (https://solidproject.org/, accessed on 25 October 2023). Solid is a free, community-led, developer-friendly, open-source initiative that delivers on the promise of decentralizing the storage of data by relying on web standards and semantic web vocabularies to promote data and services interoperability. To fulfill this vision, the Solid specification relies on authentication and authorization protocols to provide private, secure, and granular access to data stored in Solid’s personal online datastores, the so-called “Pods” [17].
As such, there have been recent efforts to align the GDPR with personal datastores and in particular with Solid. One of the more discussed issues relies on the uncertainties generated by such decentralized systems in the definition of responsibilities under the GDPR [18,19]—while some defend that in such settings data subjects become data controllers of their own data [20], a view that clashes with existing regulations [21], others maintain that the user remains the data subject and the providers and developers of such systems are data controllers.
It is, therefore, also important to make a distinction between what can be enforced technologically and what can only be legally enforced—while technically we can restrict the data that applications can have access to, and remove the access grant when we no longer want to use them, when an app can read data from a Pod, it can also copy it, even if with Solid it does not need to do it. At this point, we enter the realm of the law—where processing must comply with several principles and rules. Although the data subject wishes, as declared by the policies that they have stored in the Pod, play an important role, their legal significance depends on how and when they are expressed [22]. Additionally, to ensure that Solid is taken up on a large scale, it is important to consider the legal implications of its development and use, the responsibilities that are associated with the roles that different actors play in this configuration, and the data subject rights that must be respected.
In addition, in order to comply with the principle of lawfulness, fairness, and transparency, data subjects must identify a ground for lawfulness as per Article 6 of the GDPR. One of the legal grounds provided under this article is the consent of the data subject. The usage of lawful grounds for processing beyond consent [19,23] or dealing with access to special categories of personal data [24] was previously discussed in the literature.
In addition to the challenges around legal bases, when it comes to the alignment of Solid with data protection requirements, a number of relevant initiatives have been materializing in recent years, mainly through academic projects and publications. Pandit analyzed this technology in terms of the actors involved, according to existing standards related to cloud technology, in order to identify GDPR issues that are still applicable in decentralized settings, such as the transparency of information, purpose limitation and exercising of data subject’s rights [25]. Esposito et al. also provide a theoretical analysis of security and privacy measures to comply with the GDPR’s principles of confidentiality and data minimization and to safeguard the data subjects’ rights of notification, to object and to not be subjected to automated decision-making [26]. Other researchers have been focused on adding a legally compatible policy layer to Solid as a tool to express consent and determine access [27,28] and usage control [29] to data stored in Pods and on using the Verifiable Credential model to have an attribute-based access control mechanism [30]. Taking into consideration this ‘law+tech’ approach to the management of personal data in decentralized settings, in this work, we focus on the current efforts to introduce a policy layer to the Solid ecosystem, further developed in Section 2, as a tool to provide the necessary information and to obtain informed and valid GDPR consent. In particular, we focus on the processing of health data (considered a special category of personal data under the GDPR) for biomedical research purposes.
As such, we focus on addressing the following research question: Can the matching between user policies and data requests, in a decentralized setting such as the Solid project, signify lawful consent under the GDPR? The following challenges were identified for the implementation of a legally-aligned Solid ecosystem:
Challenge 1. Users’ policies as a precursor of consent (tackled in Section 3 and Section 4.1)—previous studies have shown that the current access control mechanisms supported by the Solid protocol are not enough to deal with GDPR requirements; however, there is work being developed to introduce a policy language—the Open Digital Rights Language (ODRL)—“for Expressing Consent through Granular Access Control Policies” [27]. User policies can enable compliance with several requirements of the GDPR. Pursuant to Articles 13 and 14 GDPR, data controllers have the obligation to provide the data subject information about the processing of their personal data, and users’ policies can enable communication of this information. Furthermore, information about the processing of personal data is a prerequisite for obtaining valid consent pursuant to Articles 7 and 4 (11) of the GDPR.
Challenge 2. Automation of consent (tackled in Section 4)—decentralized ecosystems, such as the one involving Solid Pods, rely on the existence of authorizations to provide access to (personal) data. Since the users are the ones specifying the access authorizations, said systems provide a fertile ground for research on the automation of access to resources—in this case, a data request might be automatically accepted, with no further action from the user, if the user had previously added a policy in its Pod stating that said access can be granted. Whether such automation can be considered consent under the GDPR is still up for debate. Even though there is no provision in the GDPR prohibiting the expression of consent in advance, for it to be valid, the conditions set in Article 7 and Article 4 (11) of the GDPR must also be met. In addition to the requirement of consent to be informed, the controller must be able to prove that consent was freely given, specific, and unambiguous.
Challenge 3. Dealing with health data for biomedical research (tackled in Section 5)—the processing of the GDPR’s special categories of personal data, such as data concerning health, is prohibited by default and brings extra “burdens” to data controllers. In addition to identifying a legal basis under Article 6 GDPR, they must rely on an exception under Article 9 GDPR. There are, however, certain derogations when health data are processed for scientific research or for the management of public health (for example, Article 5 (1) (b), Article 14 (5) (b), Article 9 (2) (j), Recital 33, 52 GDPR).
To address these challenges, as the main contributions of this paper, we discuss the legal requirements that need to be addressed to build a personal information management system that aims at facilitating the expression of consent and use Solid as a use case to propose solutions for improving the current status quo of consent management. The paper is organized as follows: in Section 2, we provide an overview of Solid and relevant work in the area; in Section 3, we provide a legal overview of the distinction between providing consent and granting access to data; in Section 4, we discuss the automation of consent, in particular regarding the expression of consent in advance, the specificity of purposes, the disclosure of the identity of data controllers and the special requirements related to the usage of personal data for biomedical research; and in Section 6, we discuss future research directions and provide concluding remarks.

2. Background—Decentralizing the Web with Solid

In this section, we provide an overview of Solid and its main building blocks. Its access control mechanism and the existing efforts to align it with GDPR requirements are discussed in detail, including information about the ODRL profile for access control and other Solid-related work on control and privacy.

2.1. Solid Overview

Solid presents a radical paradigm shift in relation to today’s web—by detaching data from web applications, users are given control over their data and choice over which apps they want to use with said data. This represents a major shift in power in relation to what users experience these days when they go online. By unlocking the storage of data from the hands of just a few storage providers, such as Google or Facebook, Solid gives its users the option of having a Pod—a personal online datastore—using their storage provider of choice or even hosting their own storage server [17]. While multiple users can use the same Solid server to host their data Pod, Solid’s ultimate goal is to give its users the highest possible degree of decentralization—one Pod per person, or even multiple Pods per person, with a granular access control mechanism where they can choose which people and apps have access to their Pod, to a particular container of resources stored in their Pod or even to an individual Pod resource. In this scenario, applications act as clients that can read and/or write data from/to different Pods, without storing it in their own servers. Therefore, beyond giving people control over their data, such an ecosystem “fosters innovation and competition through separate markets for data and applications” [22].
Solid’s two main building blocks (https://solidproject.org/TR/, accessed on 25 October 2023) are its authentication (https://solidproject.org/TR/oidc, accessed on 25 October 2023) and authorization protocols (https://solid.github.io/authorization-panel/authorization-ucr/, accessed on 25 October 2023). The authentication protocol is related to the identification of agents—the WebID specification (https://solid.github.io/webid-profile/, accessed on 25 October 2023) is used to identify agents through URLs, which when dereferenced, direct to a profile document that can contain information describing the agent it identifies. The authorization protocol deals with the server’s responses to requests of particular agents, in other words, it is the access control mechanism of Solid. Furthermore, the current version of the Solid protocol specification (https://solidproject.org/TR/protocol, accessed on 25 October 2023) states that, for a Solid server to be compliant, it “MUST conform to either or both Web Access Control (WAC) and Access Control Policy (ACP) specifications” (https://solidproject.org/TR/wac and https://solidproject.org/TR/acp, respectively, accessed on 25 October 2023). Further details on the authorization protocol will be given in Section 2.2. A third building block is now being developed—the Solid Application Interoperability specification (https://solid.github.io/data-interoperability-panel/specification/, accessed on 25 October 2023). Said specification details how agents and applications can interoperate and reuse data from different sources.

2.2. Access Control in Solid

As pointed out in the previous section, access control in Solid can currently be determined with two different specifications, WAC and ACP. While the Solid protocol mandates that the servers where the Pods are hosted conform to only one of the WAC or ACP access authorizations, Solid applications must comply with both or else they take the risk of not being usable by half of the ecosystem. Both solutions rely on IRIs to identify resources and agents, while WAC uses Access Control Lists (ACLs) to store authorizations, defined per resource or inherited from the parent resources, and ACP uses Access Control Resources (ACRs) to describe who is allowed or denied access to resources and access grants to represent already authorized accesses.
As illustrated by Listings 1 and 2, neither WAC nor ACP have the coverage to model the GDPR’s information requirements (Articles 13 and 14 [1]) for the processing of personal data, in particular when it comes to the modeling of the purpose for processing, personal data categories, legal basis or even information on the identity of the data requester. To overcome this issue, research has been developed in the area of using privacy policy languages as a resource to represent information related to the GDPR’s transparency requirements [31] and for the particular context of healthcare data as well [32]. Moreover, Esteves and Rodríguez-Doncel [31] describe the ODRL model as a mature solution that is “ready to be used for representing privacy-related rights and obligations” as it is open access, has good documentation, is a W3C standard for digital rights expression and has an extension mechanism that can be easily used to implement an ODRL profile for the Solid ecosystem.
Listing 1. WAC authorization that makes a WebID profile readable by any agent.
Information 14 00631 i001
Listing 2. ACP authorization that makes a WebID profile readable by any agent using any client application.
Information 14 00631 i002
ODRL (http://www.w3.org/ns/odrl/2/, accessed on 25 October 2023) [33] is a W3C standard for policy expression that includes an information model and a vocabulary of terms. It provides a convenient extension mechanism, through the definition of ODRL profiles (https://www.w3.org/profile-bp/, accessed on 25 October 2023), that can be used to create policies for different use cases, from software licenses to access and usage control policies. Since ODRL is not domain specific, i.e., it can be extended to create policies for financial (https://w3c.github.io/odrl/profile-temporal/, accessed on 25 October 2023) or language (https://rdflicense.linkeddata.es/profile.html, accessed on 25 October 2023) resources, it means that it is also not equipped to deal with legal requirements. To this end, the ODRL profile for Access Control (OAC) (https://w3id.org/oac, accessed on 25 October 2023) makes use of ODRL’s deontic representation capabilities and connects them with the Data Privacy Vocabulary (DPV) (https://w3id.org/dpv, accessed on 25 October 2023) [34] to invoke data protection-specific terms. DPV provides an ample set of taxonomies that can be used to specify entities, legal basis, personal data categories, processing activities, purposes, or technical and organizational measures. Therefore, by integrating the usage of ODRL and DPV, OAC allows Solid users to express their privacy preferences and requirements over particular types of data, purposes, recipients, or processing operations at distinct levels of specificity—from broad, e.g., allow data use for scientific research, to narrow policies, e.g., prohibit sharing a particular resource with a particular application. Figure 1 presents a diagram with the main concepts defined in OAC to express such policies. Requests for access, either from other users or from applications or services, can be modeled in a similar manner and stored in the Pod to have a record of said requests. Listings 3 and 4 illustrate an example of a user policy as an odrl:Offer and an example of a data request as an odrl:Request, respectively.
Figure 1. Core concepts of the ODRL profile for Access Control (OAC).
Listing 3. An example ODRL offer policy generated by https://solidweb.me/besteves4/profile/card#me, stating that health records data can be accessed for the purpose of health, medical or biomedical research.
Information 14 00631 i003
By integrating the usage of such a policy layer in the Solid ecosystem, the matching of users’ preferences and requests for data is possible and can be automated. OAC’s proposed matching algorithm consists of checking for subsumption between data requests and user policies—if the data request satisfies the users’ policies, then access can be provided to the Pod. On the other hand, if any prohibitions are found in the users’ policies that match the data request, access to the Pod is denied. The result of the matching is stored in the Pod for record keeping and future inspection. Thus, OAC will be used as our motivating scenario. While the decision to deny access based on user policies can be interpreted as the exercise of a data subject right, e.g., the right to object in Article 21 GDPR, this article focuses on whether the positive result of the matching can signify consent.

2.3. Other Related Works

The issue of control and privacy in Solid has been further explored by academia and industry. Beyond access, research on usage control has also been developed [29,35], with the main goal of creating tools to enforce policies and ensure that data are being used according to the users’ preferences after access has been provided. In addition, the exercising of the GDPR’s data subject rights, in particular of the Right to Data Portability [36] and the Right of Access [37], has been proven to be facilitated through the usage of Solid. Digita, a Belgium-based startup commercializing Solid solutions (https://www.digita.ai/, accessed on 25 October 2023), also published a research report reflecting on the applicability of the GDPR’s requirements to Solid implementations, in particular, regarding data exchange with consent [23]. Recent efforts also promoted a tool to generate and store OAC policies in Solid Pods [38] and evaluated the usage of the Solid Application Interoperability specification to create a User Interface for users to evaluate data requests [39]. Hochstenbach et al. are developing RDF Surfaces (https://w3c-cg.github.io/rdfsurfaces/, accessed on 25 October 2023), a Notation3 language that intends to bring first-order logic to the Semantic Web and therefore can be used to “provide enforcement of data policies using logic-based rules” [40].
Listing 4. An example ODRL Request policy made by https://solidweb.me/arya/profile/card#me, using the https://example.com/healthApp application, to use health records data from https://solidweb.me/besteves4/profile/card#me to conduct research on arterial hypertension disease.
Information 14 00631 i004
In the particular field of health research, a Solid-powered platform has been developed to manage data requests and provide consent for health-related research using DPV [41]. Solid is also being tested by the United Kingdom’s (UK’s) National Health Service (NHS) to collect and process patient data from several systems, which is then hosted in individual patient Pods owned by the patients, who can authorize their healthcare professionals to have access to the data [42].

5. The Special Case of Biomedical Research

As explained in the previous sections, the strict requirements for obtaining consent under the GDPR impose burdensome obligations on data subjects. A requirement for separate agreements for each app provider and for each specific purpose results in repeated requests for consent. In the biomedical context, the likelihood of individuals being involved in decision-making regarding their data might be lower compared to other sectors because the incentives for individuals to participate in biomedical research are different. The benefits derived from participation are usually not immediate and do not reflect on the personal situation of the individual. Therefore, the amount of effort that individuals are willing to invest (checking the Pod for new requests, reading the information notices, and approving/disapproving new access requests) might be lower, compared to, for example, information society services. There are several provisions that suggest a more flexible approach to the requirements related to consent or even to move away completely from consent.
Recital 33 GDPR suggests that broad consent is acceptable for research. Under certain conditions, data subjects can express consent to “certain areas of scientific research”, if “recognised ethical standards for scientific research” are observed. However, this possibility is limited, as individuals shall have the opportunity to “give their consent only to certain areas of research or parts of research projects”. The concepts of “areas of research” or “part of research projects” are domain-specific notions that are not defined in the GDPR, which is an omnibus regulation. The work of Pandit and Esteves on DUODRL (https://github.com/besteves4/duo-odrl-dpv/, accessed on 25 October 2023) [74], inspired by the work of the Global Alliance for Genomics and Health (https://www.ga4gh.org/, accessed on 25 October 2023) on the Data Use Ontology [79], can be reused by data subjects and data controllers to create policies for health data-sharing, as it provides a taxonomy of health-related research purposes, connects to other ontologies with taxonomies of diseases, and includes the concepts to model projects and duties to use data, e.g., the requirement to have ethical approval, the requirement for collaboration with the study’s investigator(s), or the requirement to return the generated results of the study. Listing 7 provides an example of a user policy that states that the dataset https://example.com/Dataset can be used for the purpose of health, medical or biomedical research, identified with the duodrl:HMB concept, in the context of Project X, ex:ProjectX, provided that the user or app requesting access can provide proof of having ethical approval, identified with the duodrl:ProvideEthicalApproval concept.
Listing 7. An example ODRL offer policy generated by https://solidweb.me/arya/profile/card#me, stating that a dataset can be accessed for the purpose of health, medical or biomedical research in the context of Project X, provided that the entity requesting data provides documentation of ethical approval.
Information 14 00631 i007
This provision of Recital 33 GDPR is only present in the preamble of the Regulation, which does not have binding force and is not mirrored in the text of the GDPR. Furthermore, it was interpreted narrowly by the EDPS in its preliminary opinion on Scientific Research (2020) [80]. The Supervisor states that Recital 33 does not take precedence over the provisions requiring consent to be specific, but also suggests an evaluation based on the rights of the data subject, the sensitivity of the data, the nature and purpose of the research, and the relevant ethical safeguards. At the same time, the EDPS mentions that, when purposes cannot be specified, data controllers could compensate by enhanced transparency and safeguards [80].
Looking beyond the European Union, the UK government proposed a prominent role for broad consent in medical research in its proposal for a reform of the Data Protection Act in the UK [81] and the proposal was well received, although some concerns were voiced regarding its lack of certainty and potential for abuse.
Moreover, the European Commission proposed a Regulation instrument governing the processing of health data, the European Health Data Space [82], which proposes to completely move away from consent for secondary use of personal data for biomedical research. This proposal defines a ‘data holder’ as “any natural or legal person, which is an entity or a body in the health or care sector, or performing research in relation to these sectors, as well as Union institutions, bodies, offices and agencies who has the right or obligation, in accordance with this Regulation, applicable Union law or national legislation implementing Union law, or in the case of non-personal data, through control of the technical design of a product and related services, the ability to make available, including to register, provide, restrict access or exchange certain data”. In this case, data holders have an obligation to disclose personal and non-personal data, under certain conditions and for a restricted range of purposes, including scientific research (Article 34 (1) (e) [82]) without the consent of the data subject. Article 33(5) of the EHDS Proposal also seems to overrule national laws that require consent “where the consent of the natural person is required by national law, health data access bodies shall rely on the obligations laid down in this Chapter to provide access to electronic health data”. It remains to be seen what the final versions of this proposal will be, whether consent will play a role, and whether it will be broad or specific. The proposal was criticized by the EDPB and EDPS in a joint opinion [83], which requires further clarity on the interplay between national laws requiring consent and the proposed European instrument.
In the GDPR, biomedical research poses challenges because it combines a stricter regime (because research involves processing health data, which are part of the GDPR’s special categories of data) with a series of derogations (aiming at supporting research because of its importance for society).

5.1. A Stricter Regime

The processing of special categories of data (including data concerning health) is forbidden pursuant to Article 9 (1) GDPR. There are ten exceptions to this rule, one of which is the explicit consent of the data subject. However, as mentioned in the EDPB Opinion on Consent [45], it is unclear what the explicit character refers to, since expressing a “statement or clear affirmative action” is a prerequisite for “regular” consent. For the requirements for expressing consent in the GDPR, it needs to be clarified what extra efforts a controller should undertake in order to obtain the explicit consent of a data subject in line with the GDPR [45]. The EDPB provides several examples of expressing explicit consent. The Guidance [45] mentions a written statement or in the digital or online context: filling in an electronic form, sending an email, uploading a scanned document carrying the signature of the data subject, or using an electronic signature. Two-stage verification of consent is another option for expressing explicit consent. For example, a data subject may receive an email informing them of the controller’s intention to process a medical data record. In the email, the controller states that he is requesting permission to use a specific collection of information for a specified reason. If the data subject agrees to the use of this information, the controller requests an email response with the words ‘I agree’. Following the receipt of the response, the data subject receives a verification link that must be clicked or an SMS message.
In Solid, this can be implemented in different ways. Depending on the Solid server where the users choose to host their Pod, an inbox container, similar to the email inboxes available in other ecosystems, might be present by default when the user creates the Pod and can be used to receive these special requests. This inbox container has a special access control authorization—other users, beyond the data subject of the Pod, can only write to the container, in order to ensure that only the data subject can read the resources in said container. However, since the presence of this container is not standardized across the Solid ecosystem, it cannot always be found or might be called something else, causing an interoperability problem, and hence applications cannot rely on its existence. A more refined solution relies on a graph-centric interpretation of a Pod, where “each Solid pod is a hybrid, contextualized knowledge graph, wherein ‘hybrid’ indicates first-class support for both documents and RDF statements, and ‘contextualized’ the ability to associate each of its individual documents and statements with metadata such as policies, provenance, and trust” [84]. With the proper recording of metadata, including context and provenance metadata, multiple views of the Pod can be generated as required by the different applications that the data subject wishes to use. In this case, the requests can be simply added to the graph, with no need to hardcode in the app where the requests should be written, and such requests can be visualized by the data subject using a Solid app or service compatible with this graphic-centric approach. Moreover, the work of Braun and Käfer [85] can be leveraged to sign and validate resources that carry the ‘I agree’ statement of the data subject.
We can conclude that it is difficult to express explicit consent by pre-set preferences. Matching user preferences (expressed in advance) with requests for processing personal data will, most likely, fail to comply with the explicit character of consent. While the matching can increase transparency and help the individual make a decision, a second action of approving the use of personal data is necessary in order to comply with the explicit character of consent.

5.2. A Series of Derogations

We are focusing on three aspects that are specific to the regime of health research: the presumption of compatibility between the purpose of collection and the use for research purposes, the limitation to the right to information, and alternative exceptions beyond consent that can be used to process special categories of data.
A. The purpose limitation principle The principle of purpose limitation and the compatibility assessment were discussed in Section 4.3 on “Is consent necessary for compatible purposes?”. To remind the reader, pursuant to Article 5 (1) (b) of the GDPR, “data shall be collected for specific, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes”. When data are processed for scientific research purposes, there is a presumption of compatibility between the purpose of collection and further use, if the processing is conducted in accordance with appropriate safeguards for the rights and freedoms of the data subject (as provided under Article 89 (1) GDPR). It is important to emphasize that the prohibition to process personal data for incompatible purposes is different from the requirement of purpose specificity and a derogation does not reduce the requirement for a specific purpose. As previously explained in Section 4.3, irrespective of compatibility, the data controller would have to rely on consent or another legitimate basis laid down by law. However, one provision in the preamble of the GDPR questions the separation between the two requirements. Recital 50 GDPR reads as follows: “The processing of personal data for purposes other than those for which the personal data were initially collected should be allowed only where the processing is compatible with the purposes for which the personal data were initially collected. In such a case, no legal basis separate from that which allows the collection of the personal data is required”. This seems to challenge the separation between the purpose limitation principle and the principle of lawfulness. This intersection and the effect on Solid requires further legal research.
B. The obligation to provide information We discussed the information obligations in Articles 13 and 14 GDPR in Section 4.2.3, “Specific data controllers? Or categories of recipients?” focusing on the moment when the information needs to be provided to the data subject. If personal data are processed for (biomedical) research purposes, Article 14 GDPR provides an exception for cases when personal data have not been obtained from the data subject. This may apply to Solid if we consider that not all personal data stored in Solid Pods comes directly from the data subject, e.g., it can be generated by app providers, Pod providers, or other users or agents. Pursuant to Article 14 (5) GDPR if (i) the provision of information proves impossible or would involve a disproportionate effort or it is likely to render impossible or seriously impair the achievement of the objectives of the processing and (ii) the conditions and safeguards in Article 89 GDPR are respected, the general information obligations in Article 14 do not apply. Whether these conditions are complied with in Solid will have to be assessed on a case-by-case basis, depending on the context of the request for accessing the personal data in a Pod. However, it is likely that these conditions will be met in exceptional cases and not as a rule. In case the conditions are met, the data controller “shall take appropriate measures to protect the data subject’s rights and freedoms and legitimate interests, including making the information publicly available”. Further research is necessary to discuss the role of the notification system of Solid as an appropriate measure to protect the data subject’s rights.
C. Alternative legal bases beyond consent Besides explicit consent, Article 9 (2) of the GDPR provides other exceptions from the prohibition to process special categories of data. Article 9 (2) (j) is especially relevant for this section because it refers to processing personal data for health research. This provision allows the processing of data concerning health when it is necessary for scientific research in accordance with Article 89(1) GDPR, based on Union or Member State law, which shall be proportionate to the aim pursued, respect the essence of the right to data protection and provide for suitable and specific measures to safeguard the fundamental rights and the interests of the data subject. Therefore, the application of this exception depends on the identification of a Union or Member State law that can serve as a basis for the processing of personal data. If the processing falls under the scope of such a law, the explicit consent of the data subject is not necessary.
What results from this section is that the derogations for processing personal data for scientific research depend on the implementation and application of appropriate safeguards. Pursuant to Article 89 (1) GDPR, these safeguards refer to respect for the principle of data minimization and consist of, for example, pseudonymization and techniques that do not permit the identification of data subjects. Future research can determine whether PIMS such as the matching system presented in this paper can play a role as a safeguard.

6. Concluding Remarks

The analysis presented in this paper shows that it is challenging to express consent in advance. We analyze consent as the process of setting preferences, including permissions (positive statements) and prohibitions (negative statements) expressed by the data subject and stored in Solid Pods. These statements are then matched with requests for processing personal data. Table 1 presents the main building blocks of expressing valid consent. Some of them were analyzed in this paper and others need to be further explored in future research. The validity of consent is heavily influenced by the interface built on top of Solid and the way in which the information is presented to and acknowledged by individuals.
Table 1. Overview of main building blocks for expressing consent and the discussion points raised in this paper.
Starting from our research question, how Can the matching between user policies and data requests, in a decentralized setting such as the Solid project, signify lawful consent under the GDPR?, we conclude that the GDPR does not oppose expressing consent in advance. However, we identify several requirements for obtaining valid consent and show the challenges of formalizing them in a decentralized setting. There is still much to be achieved when it comes to the alignment of Solid with legal requirements. In its current form, the OAC system does not include all the necessary elements for expressing valid consent. The answer on whether consent is valid as a ground for lawfulness will depend on future technical developments, the analysis of several other legal elements, and on the design of the interfaces that will be developed on top of Solid.
Going forward, we consider that Solid can serve an important role in ensuring compliance with data protection laws in two different ways: (a) aim for obtaining valid consent by including in the OAC profile more elements required by law and, if this is not possible, ask for new approval as they become known or better defined or (b) develop the OAC profile as a safeguard when other grounds for lawfulness, different from consent, are relied on, by ensuring transparency, traceability and user control.
As future work, we suggest several directions for further research: study the specificity of purposes and processing operations provided in taxonomies, such as the ones available in DPV, to check whether their labeling is enough for both data controllers to declare their activities and for data subjects to understand what is happening to their data, have tools to assess the compatibility of purposes to reduce the burden on users accessing similar data requests, develop a taxonomy of recipients, e.g., by industry, sector, etc., to express which recipient categories can, cannot or are receiving a copy of the personal data of the users, research on the value of PIMS for enabling compliance with legal requirements beyond consent and the use of OAC as an information mechanism and as a safeguard when other legal basis are used, implement a stricter access control mechanism for special categories of data (when health data are processed on the basis of Article 9 (2) (a) GDPR), for instance using Verifiable Credentials, and look at the requirements of new data-related laws being discussed and approved in the EU, such as the Data Governance Act, Data Act or the European Health Data Space proposal, such as the California Consumer Privacy Act (CCPA), the General Personal Data Protection Law (or Lei Geral de Proteção de Dados Pessoais—LGPD) in Brazil or the Digital Personal Data Protection Act (DPDP) in India.
More specifically, future research should develop the current analysis regarding the informed character of consent. The current paper focuses on the information concerning the purpose of processing the identity of the data controller and the recipients or categories of recipients of the personal data (highlighted in Recital 42 GDPR). Future work is necessary to determine if the other requirements listed in Articles 13 and 14 of the GDPR, for example, details regarding the storage period, influence the validity of consent and whether they can be automated. It seems that not all elements are equally important for obtaining valid consent.
In what concerns the use of PIMS beyond consent (as a legal ground for lawfulness), future work should focus on exploring whether the OAC system can function as an information mechanism and as a safeguard, together with other grounds for lawfulness (such as Article 6 (1) (f) GDPR on legitimate interests or Article 6 (1) (c) GDPR on compliance with a legal obligation) and with the special conditions for processing health data (Article 9 (2) (j) GDPR on processing necessary for scientific research purposes).

Author Contributions

Conceptualization, M.F. and B.E.; methodology, M.F. and B.E.; validation, M.F. and B.E.; investigation, M.F. and B.E.; writing—original draft preparation, M.F. and B.E.; writing—review and editing, M.F. and B.E. All authors have read and agreed to the published version of the manuscript.

Funding

This article is partially funded by the COST Action on Distributed Knowledge Graphs (CA19134), supported by COST (European Cooperation in Science and Technology). Beatriz Esteves was funded by the European Union’s Horizon 2020 research and innovation program under the Marie Skłodowska-Curie grant agreement No. 813497 (PROTECT). Marcu Florea is an Early Stage Researcher within the KnowGraphs Project, the work of which is supported by the European Union’s Horizon 2020 Research and Innovation Program under the Marie Skłodowska-Curie Innovative Training Network, grant agreement No. 860801.

Data Availability Statement

Data are contained within the article.

Acknowledgments

The authors wish to thank Pat McBennett, Harshvardhan J. Pandit, Jeanne Mifsud Bonnici and Radina Stoykova for their valuable feedback that contributed to the improvement of this work.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the Protection of Natural Persons with Regard to the Processing of Personal Data and on the Free Movement of Such Data, and Repealing Directive 95/46/EC (General Data Protection Regulation). 2018. Available online: https://eur-lex.europa.eu/eli/reg/2016/679/oj (accessed on 25 October 2023).
  2. Bradford, A. How the EU Became a Global Regulatory Power. The Brussels Effect: How the European Union Rules the World; Oxford University Press: Oxford, UK, 2019. [Google Scholar] [CrossRef]
  3. European Commission. Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions-A European Strategy for Data; European Commission: Brussels, Belgium, 2020. [Google Scholar]
  4. Regulation (EU) 2022/868 of the European Parliament and of the Council of 30 May 2022 on European Data Governance and Amending Regulation (EU) 2018/1724 (Data Governance Act) (Text with EEA Relevance). Legislative Body: CONSIL, EP. 2022. Available online: https://eur-lex.europa.eu/eli/reg/2022/868/oj (accessed on 25 October 2023).
  5. Mariani, M.M.; Ek Styven, M.; Teulon, F. Explaining the intention to use digital personal data stores: An empirical study. Technol. Forecast. Soc. Chang. 2021, 166, 120657. [Google Scholar] [CrossRef]
  6. Lovato, J.; Mueller, P.; Suchdev, P.; Dodds, P. More Data Types More Problems: A Temporal Analysis of Complexity, Stability, and Sensitivity in Privacy Policies. In Proceedings of the 2023 ACM Conference on Fairness, Accountability, and Transparency, Chicago, IL, USA, 12–15 June 2023; pp. 1088–1100. [Google Scholar] [CrossRef]
  7. Terpstra, A.; Schouten, A.P.; Rooij, A.D.; Leenes, R.E. Improving privacy choice through design: How designing for reflection could support privacy self-management. First Monday 2019, 24. [Google Scholar] [CrossRef]
  8. Linden, T.; Khandelwal, R.; Harkous, H.; Fawaz, K. The Privacy Policy Landscape After the GDPR. In Proceedings of the Privacy Enhancing Technologies, Virtual Event, 9–13 November 2020; Volume 1, pp. 47–64. [Google Scholar] [CrossRef]
  9. Mohan, J.; Wasserman, M.; Chidambaram, V. Analyzing GDPR Compliance Through the Lens of Privacy Policy. In Proceedings of the Heterogeneous Data Management, Polystores, and Analytics for Healthcare; Lecture Notes in Computer Science; Gadepally, V., Mattson, T., Stonebraker, M., Wang, F., Luo, G., Laing, Y., Dubovitskaya, A., Eds.; Springer International Publishing: Berlin, Germany, 2019; pp. 82–95. [Google Scholar] [CrossRef]
  10. Craglia, M.; Scholten, H.; Micheli, M.; Hradec, J.; Calzada, I.; Luitjens, S.; Ponti, M.; Boter, J. Digitranscope: The Governance of Digitally Transformed Society; Publications Office of the European Union: Luxembourg, 2021. [Google Scholar]
  11. Ilves, L.K.; Osimo, D. A roadmap for a fair data economy. In Policy Brief, Sitra and the Lisbon Council; Finnish Innovation Fund Sitra: Helsinki, Finland, 2019. [Google Scholar]
  12. Verbrugge, S.; Vannieuwenborg, F.; Van der Wee, M.; Colle, D.; Taelman, R.; Verborgh, R. Towards a personal data vault society: An interplay between technological and business perspectives. In Proceedings of the 2021 60th FITCE Communication Days Congress for ICT Professionals: Industrial Data—Cloud, Low Latency and Privacy (FITCE), Vienna, Austria, 29–30 September 2021; pp. 1–6. [Google Scholar] [CrossRef]
  13. European Data Protection Supervisor. TechDispatch #3/2020-Personal Information Management Systems; Technical Report; Technology and Privacy Unit of the European Data Protection Supervisor, 2021; Available online: https://edps.europa.eu/data-protection/our-work/publications/techdispatch/techdispatch-32020-personal-information_en (accessed on 25 October 2023).
  14. Janssen, H.; Cobbe, J.; Singh, J. Personal information management systems: A user-centric privacy utopia? Internet Policy Rev. 2020, 9, 1–25. [Google Scholar] [CrossRef]
  15. mydex. Attribute Prototype Project. In Technical Report (Case Study); Mydex Data Services CIC: Edinburgh, UK, 2020. [Google Scholar]
  16. Meeco. Unlocking the Power of Digital Identity and Verifiable Credentials; Final Report; Meeco, connectID, Powertech, Queensland Government Department of Transport and Main Roads and Hedera Hashgraph: Australia—Belgium—UK, 2021. Available online: https://www.meeco.me/resources/case-study-digital-identity-verifiable-credentials (accessed on 25 October 2023).
  17. Sambra, A.V.; Mansour, E.; Hawke, S.; Zereba, M.; Greco, N.; Ghanem, A.; Zagidulin, D.; Aboulnaga, A.; Berners-Lee, T. Solid: A Platform for Decentralized Social Applications Based on Linked Data; Technical Report; 2016; Available online: https://www.semanticscholar.org/paper/Solid-%3A-A-Platform-for-Decentralized-Social-Based-Sambra-Mansour/5ac93548fd0628f7ff8ff65b5878d04c79c513c4#citing-papers (accessed on 25 October 2023).
  18. Janssen, H.; Cobbe, J.; Norval, C.; Singh, J. Decentralized data processing: Personal data stores and the GDPR. Int. Data Priv. Law 2020, 10, 356–384. [Google Scholar] [CrossRef]
  19. Van Damme, S.; Mechant, P.; Vlassenroot, E.; Van Compernolle, M.; Buyle, R.; Bauwens, D. Towards a Research Agenda for Personal Data Spaces: Synthesis of a Community Driven Process. In Proceedings of the Electronic Government; Lecture Notes in Computer Science; Janssen, M., Csáki, C., Lindgren, I., Loukis, E., Melin, U., Viale Pereira, G., Rodríguez Bolívar, M.P., Tambouris, E., Eds.; Springer International Publishing: Berlin, Germany, 2022; pp. 563–577. [Google Scholar] [CrossRef]
  20. Edwards, L.; Finck, M.; Veale, M.; Zingales, N. Data subjects as data controllers: A Fashion(able) concept? Internet Policy Rev. 2019, 13. Available online: https://discovery.ucl.ac.uk/id/eprint/10076025/ (accessed on 25 October 2023).
  21. Chomczyk Penedo, A. Self-sovereign identity systems and European data protection regulations: An analysis of roles and responsibilities. In Proceedings of the Open Identity Summit 2021, Virtual Event, 1–2 June 2021; pp. 95–106. [Google Scholar]
  22. Verborgh, R. Paradigm Shifts for the Decentralized Web. 20 December 2017. Available online: https://ruben.verborgh.org/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/ (accessed on 25 October 2023).
  23. De Bot, D.; Haegemans, T. Data Sharing Patterns as a Tool to Tackle Legal Considerations about Data Reuse with Solid: Theory and Applications in Europe; Digita Research Reports; Digita BV: Brussels, Belgium, 2021. [Google Scholar]
  24. Lodge, T.; Crabtree, A.; Brown, A. Developing GDPR Compliant Apps for the Edge. In Proceedings of the Data Privacy Management, Cryptocurrencies and Blockchain Technology; Lecture Notes in Computer Science; Garcia-Alfaro, J., Herrera-Joancomartí, J., Livraga, G., Rios, R., Eds.; Springer International Publishing: Berlin, Germany, 2018; pp. 313–328. [Google Scholar] [CrossRef]
  25. Pandit, H.J. Making Sense of Solid for Data Governance and GDPR. Information 2023, 14, 114. [Google Scholar] [CrossRef]
  26. Esposito, C.; Horne, R.; Robaldo, L.; Buelens, B.; Goesaert, E. Assessing the Solid Protocol in Relation to Security and Privacy Obligations. Information 2023, 14, 411. [Google Scholar] [CrossRef]
  27. Esteves, B.; Pandit, H.J.; Rodríguez-Doncel, V. ODRL Profile for Expressing Consent through Granular Access Control Policies in Solid. In Proceedings of the 2021 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), Vienna, Austria, 6–10 September 2021; pp. 298–306, ISSN 2768-0657. [Google Scholar] [CrossRef]
  28. Debackere, L.; Colpaert, P.; Taelman, R.; Verborgh, R. A Policy-Oriented Architecture for Enforcing Consent in Solid. In Proceedings of the Companion of the Web Conference 2022, WWW ’22, Lyon, France, 25–29 April 2022; pp. 516–524. [Google Scholar] [CrossRef]
  29. Akaichi, I. Semantic Technology based Usage Control for Decentralized Systems. arXiv 2022, arXiv:2206.04947. [Google Scholar] [CrossRef]
  30. Braun, C.H.J.; Käfer, T. Attribute-based Access Control on Solid Pods using Privacy-friendly Credentials. In Proceedings of the Poster and Demo Track and Workshop Track of the 18th International Conference on Semantic Systems Co-Located with 18th International Conference on Semantic Systems (SEMANTiCS 2022), Vienna, Austria, 13–15 September 2022. [Google Scholar]
  31. Esteves, B.; Rodríguez-Doncel, V. Analysis of Ontologies and Policy Languages to Represent Information Flows in GDPR. Semant. Web 2022, 1–35. Available online: https://content.iospress.com/articles/semantic-web/sw223009 (accessed on 25 October 2023). [CrossRef]
  32. Becher, S.; Gerl, A.; Meier, B.; Bölz, F. Big Picture on Privacy Enhancing Technologies in e-Health: A Holistic Personal Privacy Workflow. Information 2020, 11, 356. [Google Scholar] [CrossRef]
  33. Iannella, R.; Villata, S. ODRL Information Model 2.2. 2018. Available online: https://www.w3.org/TR/odrl-model/ (accessed on 25 October 2023).
  34. Pandit, H.J.; Polleres, A.; Bos, B.; Brennan, R.; Bruegger, B.; Ekaputra, F.J.; Fernández, J.D.; Hamed, R.G.; Kiesling, E.; Lizar, M.; et al. Creating a Vocabulary for Data Privacy: The First-Year Report of Data Privacy Vocabularies and Controls Community Group (DPVCG). In Proceedings of the On the Move to Meaningful Internet Systems: OTM 2019 Conferences; Panetto, H., Debruyne, C., Hepp, M., Lewis, D., Ardagna, C.A., Meersman, R., Eds.; Springer International Publishing: Berlin, Germany, 2019; Volume 11877, pp. 714–730. [Google Scholar] [CrossRef]
  35. Havur, G.; Sande, M.; Kirrane, S. Greater Control and Transparency in Personal Data Processing. In Proceedings of the 6th International Conference on Information Systems Security and Privacy; SCITEPRESS-Science and Technology Publications: Setúbal, Portugal, 2020; pp. 655–662. [Google Scholar] [CrossRef]
  36. De Mulder, G.; De Meester, B.; Heyvaert, P.; Taelman, R.; Dimou, A.; Verborgh, R. PROV4ITDaTa: Transparent and direct transferof personal data to personal stores. In Proceedings of the Companion Proceedings of the Web Conference 2021; WWW ’21; Association for Computing Machinery: New York, NY, USA, 2021; pp. 695–697. [Google Scholar] [CrossRef]
  37. Esteves, B.; Rodríguez-Doncel, V.; Longares, R. Automating the Response to GDPR’s Right of Access. In Legal Knowledge and Information Systems; IOS Press: Amsterdam, The Netherlands, 2022; pp. 170–175. [Google Scholar] [CrossRef]
  38. Esteves, B.; Rodríguez-Doncel, V.; Pandit, H.J.; Mondada, N.; McBennett, P. Using the ODRL Profile for Access Control for Solid Pod Resource Governance. In Proceedings of the The Semantic Web: ESWC 2022 Satellite Events; Lecture Notes in Computer Science; Groth, P., Rula, A., Schneider, J., Tiddi, I., Simperl, E., Alexopoulos, P., Hoekstra, R., Alam, M., Dimou, A., Tamper, M., Eds.; Springer International Publishing: Berlin, Germany, 2022; pp. 16–20. [Google Scholar] [CrossRef]
  39. Bailly, H.; Papanna, A.; Brennan, R. Prototyping an End-User User Interface for the Solid Application Interoperability Specification Under GDPR. In Proceedings of the The Semantic Web; Lecture Notes in Computer Science; Pesquita, C., Jimenez-Ruiz, E., McCusker, J., Faria, D., Dragoni, M., Dimou, A., Troncy, R., Hertling, S., Eds.; Springer Nature: Basel, Switzerland, 2023; pp. 557–573. [Google Scholar] [CrossRef]
  40. Hochstenbach, P.; De Roo, J.; Verborgh, R. RDF Surfaces: Computer Says No. In Proceedings of the 1st Workshop on Trusting Decentralised Knowledge Graphs and Web Data, Hersonissos, Greece, 28–29 May 2023. [Google Scholar]
  41. Sun, C.; Gallofré Ocaña, M.; van Soest, J.; Dumontier, M. ciTIzen-centric DAta pLatform (TIDAL): Sharing distributed personal data in a privacy-preserving manner for health research. Semant. Web 2023, 14, 977–996. [Google Scholar] [CrossRef]
  42. Janeiro Digital at Solid World: NHS Personal Health Stores with XFORM Health and Solid. 2021. Available online: https://www.janeirodigital.com/blog/janeiro-digital-at-solid-world-nhs-personal-health-stores-with-xform-health-and-solid/ (accessed on 25 October 2023).
  43. Kranenborg, H.R. Article 8—Protection of Personal Data. In The EU Charter of Fundamental Rights; Hart Publishing: Melbourne, Australia, 2014. [Google Scholar]
  44. European Data Protection Board. Guidelines 2/2019 on the Processing of Personal Data under Article 6(1)(b) GDPR in the Context of the Provision of Online Services to Data Subjects. 2019. Available online: https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22019-processing-personal-data-under-article-61b_en (accessed on 25 October 2023).
  45. European Data Protection Board. Guidelines 05/2020 on Consent under Regulation 2016/679 Version 1.1; 2020. Available online: https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en (accessed on 25 October 2023).
  46. Article 29 Data Protection Working Party. Opinion 15/2011 on the Definition of Consent; 2011. Available online: https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjW0tHkv9uCAxVCVPUHHSTEBKYQFnoECBMQAQ&url=https%3A%2F%2Fec.europa.eu%2Fjustice%2Farticle-29%2Fdocumentation%2Fopinion-recommendation%2Ffiles%2F2011%2Fwp187_en.pdf&usg=AOvVaw10VgxVoUsNcWlOUWTAEO2E&opi=89978449 (accessed on 25 October 2023).
  47. Article 29 Data Protection Working Party. Guidelines on Consent under Regulation 2016/679. 2016. Available online: https://uk.practicallaw.thomsonreuters.com/w-014-5649?transitionType=Default&contextData=(sc.Default)&firstPage=true (accessed on 25 October 2023).
  48. Jarovsky, L. Improving Consent in Information Privacy Through Autonomy-Preserving Protective Measures (APPMs). Eur. Data Prot. Law Rev. 2018, 4, 447–458. [Google Scholar] [CrossRef]
  49. Solove, D.J. Privacy Self-Management and the Consent Dilemma. Harv. Law Rev. 2012, 126, 1880. [Google Scholar]
  50. McDonald, A.M.; Cranor, L.F. The Cost of Reading Privacy Policies. I/S J. Law Policy Inf. Soc. 2008, 4, 543–568. [Google Scholar]
  51. Solove, D.J. Murky Consent: An Approach to the Fictions of Consent in Privacy Law. Boston Univ. Law Rev. 2023. Forthcoming. [Google Scholar] [CrossRef]
  52. Kosta, E. Consent in European Data Protection Law; Martinus Nijhoff Publishers: Leiden, The Netherlands, 2013. [Google Scholar]
  53. Orange Romania SA v Autoritatea Naţională de Supraveghere a Prelucrării Datelor cu Caracter Personal (ANSPDCP). 2020. Available online: https://mybiz.eu/orange-romania-vs-anspdcp-care-a-fost-decizia-curtii-de-justitie-a-uniunii-europene/ (accessed on 25 October 2023).
  54. Kamara, I.; Kosta, E. Do Not Track initiatives: Regaining the lost user control. Int. Data Priv. Law 2016, 6, 276–290. [Google Scholar] [CrossRef]
  55. Cranor, L.; Langheinrich, M.; Marchiori, M.; Presler-Marshall, M.; Reagle, J. The Platform for Privacy Preferences 1.0 (P3P1.0) Specification. W3C Recommendation 16 April 2002 Obsoleted 30 August 2018. 2002. Available online: https://www.w3.org/TR/P3P/ (accessed on 25 October 2023).
  56. Cranor, L. Web Privacy with P3P, 1st ed.; O’Reilly Media, Inc.: Sebastopol, CA, USA, 2002. [Google Scholar]
  57. Article 29 Data Protection Working Party. Article 29 Data Protection Working Party Comments in Response to W3C’s Public Consultation on the W3C Last Call Working Draft, 24 April 2014, Tracking Preference Expression (DNT). Available online: https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwiB3ZPvxNmCAxVuplYBHUr2ArUQFnoECAsQAQ&url=https%3A%2F%2Fec.europa.eu%2Fjustice%2Farticle-29%2Fdocumentation%2Fother-document%2Ffiles%2F2014%2F20140606_wp29_ts_standardisation_letter_to_w3c.pdf&usg=AOvVaw0WPgtw91NVobgLCvuSVhnP&opi=89978449 (accessed on 25 October 2023).
  58. Directive 2009/136/EC of the European Parliament and of the Council of 25 November 2009 Amending Directive 2002/22/EC on Universal Service and Users’ Rights Relating to Electronic Communications Networks and Services, Directive 2002/58/EC Concerning the Processing of Personal Data and the Protection of Privacy in the Electronic Communications Sector and Regulation (EC) No 2006/2004 on Cooperation between National Authorities Responsible for the Enforcement of Consumer Protection Laws. 2009. Available online: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32009L0136 (accessed on 25 October 2023).
  59. Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002 Concerning the Processing of Personal Data and the Protection of Privacy in the Electronic Communications Sector (Directive on Privacy and Electronic Communications). 2002. Available online: https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32002L0058 (accessed on 25 October 2023).
  60. Legea 506/2004 Privind Prelucrarea Datelor cu Caracter Personal si Protectia Vietii Private in Sectorul Comunicatiilor Electronice. 2004. Available online: https://www.cdep.ro/pls/legis/legis_pck.htp_act?ida=53465 (accessed on 25 October 2023).
  61. Global Privacy Control. GPC Privacy Browser Signal Now Used by Millions and Honored By Major Publishers. 2021. Available online: https://globalprivacycontrol.org/press-release/20210128 (accessed on 25 October 2023).
  62. Human, S.; Schrems, M.; Toner, A.; Gerben; Wagner, B. Advanced Data Protection Control (ADPC). 2021. Available online: https://www.dataprotectioncontrol.org/spec/ (accessed on 25 October 2023).
  63. Santos, C.; Pandit, H.J. How Could the Upcoming ePrivacy Regulation Recognise Enforceable Privacy Signals in the EU? 2023. Available online: https://osf.io/xvyf3/ (accessed on 25 October 2023).
  64. Article 29 Data Protection Working Party. WP 29 Working Document on the Processing of Personal Data Relating to Health in Electronic Health Records (EHR). 2007. Available online: https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjG4rf80NmCAxWVsVYBHZX2BGYQFnoECAwQAQ&url=https%3A%2F%2Fec.europa.eu%2Fjustice%2Farticle-29%2Fdocumentation%2Fopinion-recommendation%2Ffiles%2F2007%2Fwp131_en.pdf&usg=AOvVaw1SQ4vq5KPGh3RkyTrT8XlV&opi=89978449 (accessed on 25 October 2023).
  65. Nissenbaum, H. Privacy as Contextual Integrity. Wash. Law Rev. 2004, 79, 119. [Google Scholar]
  66. Koning, M. The Purpose and Limitation of the Purpose Limitation Principle. Ph.D. Thesis, Radboud University Nijmegen, Nijmegen, The Netherlands, 2020. [Google Scholar]
  67. Article 29 Data Protection Working Party. Opinion 03/2013 on Purpose Limitation. 2013. Available online: https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjg6NO60dmCAxUbplYBHSZSAyUQFnoECA0QAQ&url=https%3A%2F%2Fec.europa.eu%2Fjustice%2Farticle-29%2Fdocumentation%2Fopinion-recommendation%2Ffiles%2F2013%2Fwp203_en.pdf&usg=AOvVaw0lMPBHpQ5j-fOb4Ergot8C&opi=89978449 (accessed on 25 October 2023).
  68. European Parliament, European Union Council and European Commission. Charter of Fundamental Rights of the European Union. 2000. Available online: https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwj6tJXY0dmCAxVCplYBHTeuCTkQFnoECBUQAQ&url=https%3A%2F%2Fwww.europarl.europa.eu%2Fcharter%2Fpdf%2Ftext_en.pdf&usg=AOvVaw1IAyFXD1jcoLCBl6p5R1r4&opi=89978449 (accessed on 25 October 2023).
  69. Koops, B.J. The concept of function creep. Law Innov. Technol. 2021, 13, 29–56. [Google Scholar] [CrossRef]
  70. Article 29 Data Protection Working Party. Guidelines on Transparency under Regulation 2016/679. 2016. Available online: https://ec.europa.eu/newsroom/article29/items/622227/en (accessed on 25 October 2023).
  71. European Data Protection Board. Guidelines 07/2020 on the Concepts of Controller and Processor in the GDPR. 2020. Available online: https://edpb.europa.eu/our-work-tools/documents/public-consultations/2020/guidelines-072020-concepts-controller-and_en (accessed on 25 October 2023).
  72. Vogel, Y.A. Stretching the Limit, the Functioning of the GDPR’s Notion of Consent in the Context of Data Intermediary Services. Eur. Data Prot. Law Rev. 2022, 8, 238–249. [Google Scholar] [CrossRef]
  73. Esteves, B.; Pandit, H.J. Using Patterns to Manage Governance of Solid Apps. In Proceedings of the 14th Workshop on Ontology Design and Patterns (WOP 2023@ISWC 2023) (To Appear), Athens, Greece, 6–7 November 2023. [Google Scholar] [CrossRef]
  74. Pandit, H.J.; Esteves, B. Enhancing Data Use Ontology (DUO) for Health-Data Sharing by Extending it with ODRL and DPV. Under Revis. Semant. Web J. 2023. Available online: https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwiL4tye0tmCAxVs1DQHHcH_DLMQFnoECAsQAQ&url=https%3A%2F%2Fwww.semantic-web-journal.net%2Fsystem%2Ffiles%2Fswj3127.pdf&usg=AOvVaw2LzZ3J3tf-Jvpn2Ye62fgo&opi=89978449 (accessed on 25 October 2023).
  75. Colnago, J.; Cranor, L.F.; Acquisti, A.; Stanton, K.H. Is it a concern or a preference? An investigation into the ability of privacy scales to capture and distinguish granular privacy constructs. In Proceedings of the 18th Symposium on Usable Privacy and Security (SOUPS 2022), Boston, MA, USA, 7–9 August 2022; pp. 331–346. [Google Scholar]
  76. Boers, S.N.; van Delden, J.J.M.; Bredenoord, A.L. Broad Consent Is Consent for Governance. Am. J. Bioeth. 2015, 15, 53–55. [Google Scholar] [CrossRef] [PubMed]
  77. Le Métayer, D.; Monteleone, S. Automated consent through privacy agents: Legal requirements and technical architecture. Comput. Law Secur. Rev. 2009, 25, 136–144. [Google Scholar] [CrossRef]
  78. Sheehan, M. Can Broad Consent be Informed Consent? Public Health Ethics 2011, 4, 226–235. [Google Scholar] [CrossRef] [PubMed]
  79. Woolley, J.P.; Kirby, E.; Leslie, J.; Jeanson, F.; Cabili, M.N.; Rushton, G.; Hazard, J.G.; Ladas, V.; Veal, C.D.; Gibson, S.J.; et al. Responsible sharing of biomedical data and biospecimens via the “Automatable Discovery and Access Matrix” (ADA-M). npj Genom. Med. 2018, 3, 1–6. [Google Scholar] [CrossRef] [PubMed]
  80. European Data Protection Supervisor. A Preliminary Opinion on Data Protection and Scientific Research. 2020. Available online: https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjP4Mu70tmCAxUxslYBHZMACz8QFnoECAgQAQ&url=https%3A%2F%2Fedps.europa.eu%2Fsites%2Fedp%2Ffiles%2Fpublication%2F20-01-06_opinion_research_en.pdf&usg=AOvVaw2hleaFjGVRN9zu5XILmndZ&opi=89978449 (accessed on 25 October 2023).
  81. UK Government. Consultation Outcome-Data: A New Direction-Government Response to Consultation. 2022. Available online: https://www.gov.uk/government/consultations/data-a-new-direction/outcome/data-a-new-direction-government-response-to-consultation (accessed on 25 October 2023).
  82. Proposal for a Regulation of the European Parliament and of the Council on the European Health Data Space. 2022. Available online: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A52022PC0197 (accessed on 25 October 2023).
  83. EDPB-EDPS Joint Opinion 03/2022 on the Proposal for a Regulation on the European Health Data Space. 2022. Available online: https://edpb.europa.eu/our-work-tools/our-documents/edpbedps-joint-opinion/edpb-edps-joint-opinion-032022-proposal_en (accessed on 25 October 2023).
  84. Dedecker, R.; Slabbinck, W.; Wright, J.; Hochstenbach, P.; Colpaert, P.; Verborgh, R. What’s in a Pod?—A knowledge graph interpretation for the Solid ecosystem. In Proceedings of the 6th Workshop on Storing, Querying and Benchmarking Knowledge Graphs, Hangzhou, China, 23–27 October 2022; CEURWorkshop Proceedings. Saleem, M., Ngonga Ngomo, A.C., Eds.; Universität Paderborn, Data Science Group: Paderborn, Germany, 2022; Volume 3279, pp. 81–96. [Google Scholar]
  85. Braun, C.H.J.; Käfer, T. Self-verifying Web Resource Representations Using Solid, RDF-Star and Signed URIs. In Proceedings of the Semantic Web: ESWC 2022 Satellite Events; Lecture Notes in Computer Science; Groth, P., Rula, A., Schneider, J., Tiddi, I., Simperl, E., Alexopoulos, P., Hoekstra, R., Alam, M., Dimou, A., Tamper, M., Eds.; Springer International Publishing: Berlin, Germany, 2022; pp. 138–142. [Google Scholar] [CrossRef]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
Download PDF
Dual-Pyramid Wide Residual Network for Semantic Segmentation on Cross-Style Datasets
Previous
Enhancing Strategic Planning of Projects: Selecting the Right Product Development Methodology
Next