1. Introduction

2. Background –- Decentralising the Web with Solid

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

As illustrated by Listings 1 and 2, neither WAC nor ACP have the coverage to model GDPR’s information requirements (Articles 13 and 14 [1]) for the processing of personal data, in particular when it comes to the modelling 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 integrating the ODRL model into the Solid ecosystem.

As illustrated by Listings 1 and 2, neither WAC nor ACP have the coverage to model GDPR’s information requirements ( Articles 13 and 14 GDPR) for the processing of personal data, in particular when it comes to the modelling 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 integrating the ODRL model into the Solid ecosystem [22,23].

Listing 1. WAC authorization that makes a WebID profile, https://solidweb.me/besteves4/profile/card, readable by any agent.

Listing 2. ACP authorization that makes a WebID profile, https://solidweb.me/besteves4/profile/card, readable by any agent using any client application.

ODRL12 [27] is a W3C standard for policy expression which includes an information model and a vocabulary of terms. It provides a convenient extension mechanism, through the definition of ODRL profiles13, that can be used to create policies for different use cases, from software licences to access and usage control policies. Since ODRL is not domain specific, e.g., it can be extended to create policies for financial14 or language15 resources, it means that it is also not equipped to deal with legal requirements. To this end, the ODRL profile for Access Control (OAC)16 makes use of ODRL’s deontic representation capabilities and connects them with the Data Privacy Vocabulary (DPV)17 [28] 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 organisational 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 modelled 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.

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.

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.

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 [1], this article focuses on whether the positive result of the matching can signify consent.

3. Describing the distinction between consent and granting access to a resource

Apart from the requirements for lawfulness, GDPR provides information obligations that aim to respect the principle of transparency. Articles 12 and 14 [1] require data controllers to take appropriate measures to provide the data subject with information regarding the processing of their personal data and users’ policies can function as an information mechanism. The result of the matching exercise is stored in a known location in the Pod, where the data subjects can easily access and check the result, enabling them to easily comprehend whether the agreed specific conditions for processing personal data differ from the pre-set of preferences stored in the Pod. Listing 5 presents the ODRL agreement generated as the result of the matching exercise between the data request in Listing 4 and the user policy in Listing 3. Since the personal data type in the user policy, i.e., health records, matches the requested personal data type, and the requested purpose for processing is “to conduct research on arterial hypertension”, which is a subclass of health, medical or biomedical research –- the purpose allowed by the user policy –-, an agreement between the data subject and controller is generated and stored in the Pod, allowing the controller to access said data. Such a record also allows the user to check which entities requested access to the data.

Listing 5. An example ODRL Agreement policy that grants https://solidweb.me/arya/profile/card#me read access to health records data from https://solidweb.me/besteves4/profile/card#me to conduct research on arterial hypertension disease.

4. Can consent be automated?

4.4. 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 the 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 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 not connected to immediate benefits. Furthermore, these benefits usually do not reflect on the personal situation of the individual but have broad effects on society. 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 [1] 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 omnibus regulation. The work of Pandit and Esteves on DUODRL26 [51], inspired by the work of the Global Alliance for Genomics and Health27 on the Data Use Ontology [56], 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., requirement to have ethical approval, requirement of collaboration with the study’s investigator(s), or requirement to return the generated results of the study. Listing 6 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 6. 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.

This provision of Recital 33 [1] 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) [57].

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 [58] 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 [59], which proposes to completely move away from consent for secondary use of personal data for biomedical research. 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) [59]) without the consent of the data subject. Article 33(5) of the EHDS Proposal seems to also 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 would be, whether consent will play a role and whether it will be broad or specific. The proposal was criticised by the EDPB and EDPS in a joint opinion [60] 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 GDPR’s special categories of data) with a series of derogations (aiming at supporting research because of its importance for society).

4.4.1. A stricter regime

The processing of special categories of data (including data concerning health) is forbidden pursuant to Article 9 (1) [1]. There are ten exceptions from this rule, one of which is the explicit consent of the data subject. However, as mentioned in the EDPB Opinion on Consent [41], it is unclear what the explicit character refers to, since expressing a “statement or clear affirmative action” is a prerequisite for `regular’ consent. As 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 [41]. EDPB provides several examples of expressing explicit consent. The Guidance [41] mentions a written statement or in the digital or online context: filling in an electronic form, by sending an email, by uploading a scanned document carrying the signature of the data subject, or by using an electronic signature. Two-stage verification of consent is another option for expressing explicit consent. For example, a data subject may get 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 standardised 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’ [61]. 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 visualised by the data subject using a Solid app or service compatible with this graphic-centric approach. Moreover, the work of Braun and Käfer [62] 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.

4.4.2. A series of derogations

A. The purpose limitation principle

The principle of purpose limitation and the compatibility assessment were discussed in Section 4.2.2 on “Assessing compatibility between preferences and requests”. To remind the reader, pursuant to Article 5 (1) b) [1], `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 is 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) [1]). However, the effects of this presumption are not straightforward and depend on the relation between the purpose limitation principle and the principle of lawfulness. The WP29 Opinion on Purpose Limitation [63] provides that purpose limitation and the requirement to have a legal ground are two separate and cumulative requirements. Article 8 of the Charter of Fundamental Rights of the European Union (CFREU) [64] mentions specificity of purpose separate from the requirement for consent or another legitimate basis. Therefore, 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 [1] 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.’ Thus, the intersection between the two principles, described above, 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 [1] in Section 4.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 is processed for (biomedical) research purposes, Article 14 [1] provides an exception for cases when personal data has 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) [1] 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 [1] are respected, the general information obligations in Article 14 do not apply. 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 whether the notification system of Solid could serve as an appropriate measure to protect the data subject’s rights.

C. Alternative legal bases beyond consent

Besides explicit consent, Article 9 (2) [1] 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) [1], 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.

It results from this section that the derogations for processing personal data for scientific research depend on the implementation and application of appropriate safeguards. Pursuant to Article 89 (1) [1], these safeguards refer to respect for the principle of data minimization and consist of, for example, pseudonymisation 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.

5. Future Research & Concluding Remarks

References

1. Regulation (EU) 2016/679 of the European Parliament and of the Council of 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. 27 April.
2. Bradford, A. The Brussels Effect: How the European Union Rules the World; Oxford University Press, 2019. [CrossRef]
3. 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]
4. Linden, T.; Khandelwal, R.; Harkous, H.; Fawaz, K. The Privacy Policy Landscape After the GDPR. In Proceedings of the Proceedings on Privacy Enhancing Technologies, Vol. 1; 2020; pp. 47–64. [Google Scholar] [CrossRef]
5. 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; Gadepally, V.; Mattson, T.; Stonebraker, M.; Wang, F.; Luo, G.; Laing, Y.; Dubovitskaya, A., Eds. Springer International Publishing, Lecture Notes in Computer Science; 2019; pp. 82–95. [Google Scholar] [CrossRef]
6. 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, 2020.
7. Regulation (EU) 2022/868 of the European Parliament and of the Council of on European data governance and amending Regulation (EU) 2018/1724 (Data Governance Act) (Text with EEA relevance), 2022. Legislative Body: CONSIL, EP. 30 May.
8. Mariani, M.M.; Ek Styven, M.; Teulon, F. Explaining the intention to use digital personal data stores: An empirical study. Technological Forecasting and Social Change 2021, 166. [Google Scholar] [CrossRef]
9. 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, 2021.
10. Ilves, L.K.; Osimo, D. A roadmap for a fair data economy. Policy Brief, Sitra and the Lisbon Council, 2019.
11. 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); 2021; pp. 1–6. [Google Scholar] [CrossRef]
12. Supervisor, E.D.P. TechDispatch #3/2020 - Personal Information Management Systems. Technical report, 2021.
13. Janssen, H.; Cobbe, J.; Singh, J. Personal information management systems: a user-centric privacy utopia? Internet Policy Review 2020, 9. [Google Scholar] [CrossRef]
14. Janssen, H.; Cobbe, J.; Norval, C.; Singh, J. Decentralized data processing: personal data stores and the GDPR. International Data Privacy Law 2020, 10, 356–384. [Google Scholar] [CrossRef]
15. 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; 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, Lecture Notes in Computer Science; 2022; pp. 563–577. [Google Scholar] [CrossRef]
16. Edwards, L.; Finck, M.; Veale, M.; Zingales, N. Data subjects as data controllers: a Fashion(able) concept? Internet Policy Review 2019. [Google Scholar]
17. 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. Gesellschaft für Informatik e.V. 2021; pp. 95–5468. [Google Scholar]
18. Verborgh, R. Paradigm shifts for the decentralized Web, 2017-12-20.
19. 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, 2021.
20. Lodge, T.; Crabtree, A.; Brown, A. Developing GDPR Compliant Apps for the Edge. In Proceedings of the Data Privacy Management, Cryptocurrencies and Blockchain Technology; Garcia-Alfaro, J.; Herrera-Joancomartí, J.; Livraga, G.; Rios, R., Eds. Springer International Publishing, Lecture Notes in Computer Science; 2018; pp. 313–328. [Google Scholar] [CrossRef]
21. Pandit, H.J. Making Sense of Solid for Data Governance and GDPR. Information 2023, 14. [Google Scholar] [CrossRef]
22. 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); 2021; pp. 298–0657. [Google Scholar] [CrossRef]
23. Debackere, L.; Colpaert, P.; Taelman, R.; Verborgh, R. A Policy-Oriented Architecture for Enforcing Consent in Solid. In Proceedings of the Companion Proceedings of the Web Conference 2022.; pp. 202222516–524. [CrossRef]
24. Akaichi, I. Semantic Technology based Usage Control for Decentralized Systems, [2206.04947 [cs, eess]]. [CrossRef]
25. Braun, C.H.J.; Käfer, T. Attribute-based Access Control on Solid Pods using Privacy-friendly Credentials. In Proceedings of the 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); 2022. [Google Scholar]
26. 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.
27. Iannella, R.; Villata, S. ODRL Information Model 2.2, URL: https://www.w3.org/TR/odrl-model/, 2018.
28. 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, Vol. 11877; 2019; pp. 714–730. [Google Scholar] [CrossRef]
29. Havur, G.; Sande, M.; Kirrane, S. Greater Control and Transparency in Personal Data Processing:. In Proceedings of the Proceedings of the 6th International Conference on Information Systems Security and Privacy. [CrossRef]
30. 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.; pp. 202121695–697. [CrossRef]
31. 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, 2022; pp. 170–175. [CrossRef]
32. 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; Groth, P.; Rula, A.; Schneider, J.; Tiddi, I.; Simperl, E.; Alexopoulos, P.; Hoekstra, R.; Alam, M.; Dimou, A.; Tamper, M., Eds. Springer International Publishing, Lecture Notes in Computer Science; 2022; pp. 16–20. [Google Scholar] [CrossRef]
33. 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; Pesquita, C.; Jimenez-Ruiz, E.; McCusker, J.; Faria, D.; Dragoni, M.; Dimou, A.; Troncy, R.; Hertling, S., Eds. Springer Nature Switzerland, Lecture Notes in Computer Science; 2023; pp. 557–573. [Google Scholar] [CrossRef]
34. 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; 2023. [Google Scholar]
35. 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. Semantic Web, I: 14, 977–996. Publisher; -01. [CrossRef]
36. Janeiro Digital at Solid World: NHS Personal Health Stores with XFORM Health and Solid, 2021.
37. Ausloos, J.; Ausloos, J. The Right to Erasure in EU Data Protection Law; Oxford Data Protection & Privacy Law, Oxford University Press, 2020.
38. Lynskey, O. The Foundations of EU Data Protection Law; Oxford Studies in European Law, Oxford University Press, 2015.
39. Kranenborg, H.R. Article 8 – Protection of Personal Data. In The EU Charter of Fundamental Rights; Hart Publishing, 2014.
40. 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.
41. European Data Protection Board. Guidelines 05/2020 on Consent under Regulation 2016/679 Version 1.1, 2020.
42. Article 29 Data Protection Working Party. Opinion 15/2011 on the definition of consent.
43. Article 29 Data Protection Working Party. Guidelines on consent under Regulation 2016/679.
44. Solove, D.J. Privacy Self-Management and the Consent Dilemma. Harvard Law Review 2012, 126. [Google Scholar]
45. Kosta, E. Consent in European Data Protection Law; Martinus Nijhoff Publishers, 2013.
46. 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, , Tracking Preference Expression (DNT). 24 April.
47. Directive 2002/58/EC of the European Parliament and of the Council of concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications), 2002. 12 July.
48. Legea 506/2004 Privind Prelucrarea Datelor cu Caracter Personal si Protectia Vietii Private in Sectorul Comunicatiilor Electronice.
49. Article 29 Data Protection Working Party. WP 29 Working Document on the processing of personal data relating to health in electronic health records (EHR).
50. Nissenbaum, H. Privacy as Contextual Integrity. Washington Law Review 2004, 79, 119. [Google Scholar]
51. Pandit, H.J.; Esteves, B. Enhancing Data Use Ontology (DUO) for Health-Data Sharing by Extending it with ODRL and DPV. Under Revision in the Semantic Web Journal 2023. [Google Scholar]
52. Colnago, J.; Cranor, L.F.; Acquisti, A.; Stanton, K.H. Is it a concern or a preference? In 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); 2022; pp. 331–346. [Google Scholar]
53. Sheehan, M. Can Broad Consent be Informed Consent? Public Health Ethics 2011, 4, 226–235. [Google Scholar] [CrossRef] [PubMed]
54. Article 29 Data Protection Working Party. Guidelines on Transparency under Regulation 2016/679, 2018.
55. European Data Protection Board. Guidelines 07/2020 on the concepts of controller and processor in the GDPR, 2020.
56. 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 Genomic Medicine 2018, 3, 1–6. [Google Scholar] [CrossRef] [PubMed]
57. European Data Protection Supervisor. A Preliminary Opinion on data protection and scientific research, 2020.
58. UK Government. Consultation outcome - Data: a new direction - government response to consultation, 2022.
59. Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on the European Health Data Space, 2022.
60. EDPB-EDPS Joint Opinion 03/2022 on the Proposal for a Regulation on the European Health Data Space, 2022.
61. 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 Proceedings of the 6th Workshop on Storing, Querying and Benchmarking Knowledge Graphs; pp. 2022327981–96.
62. Braun, C.H.J.; Käfer, T. Self-verifying Web Resource Representations Using Solid, RDF-Star and Signed URIs. In Proceedings of the The Semantic Web: ESWC 2022 Satellite Events; Groth, P.; Rula, A.; Schneider, J.; Tiddi, I.; Simperl, E.; Alexopoulos, P.; Hoekstra, R.; Alam, M.; Dimou, A.; Tamper, M., Eds. Springer International Publishing, Lecture Notes in Computer Science; 2022; pp. 138–142. [Google Scholar] [CrossRef]
63. Article 29 Data Protection Working Party. Opinion 03/2013 on purpose limitation, 2013.
64. Charter of Fundamental Rights of the European Union, 2000.