How to Manage My Data? With Machine--Interpretable GDPR Rights!

Abstract: The EU GDPR is a landmark regulation that introduced several rights for individuals to obtain information and control how their personal data is being processed, as well as receive a copy of it. However, there are gaps in the effective use of rights due to each organisation developing custom methods for rights declaration and management. Simultaneously, there is a technological gap as there is no single consistent standards-based mechanism that can automate the handling of rights for both organisations and individuals. In this article, we present a specification for exercising and managing rights in a machine-interpretable format based on semantic web standards. Our approach uses the comprehensive Data Privacy Vocabulary to create a streamlined workflow for individuals to understand what rights exist, how and where to exercise them, and for organisations to effectively manage them. This work pushes the state of the art in GDPR rights management and is crucial for data reuse and rights management under technologically intensive developments, such as Data Spaces.

Introduction

The General Data Protection Regulation (GDPR) [1] grants data subjects a set of rights designed to protect their personal data and to ensure that they have greater control over how their data is collected, processed, and used by organisations. These rights include the right to access personal data, the right to rectification of inaccurate data, the right to erasure (commonly known as the “right to be forgotten”), and the right to data portability, which allows individuals to ask for their data to be transferred between data controllers. Additionally, the GDPR provides rights to restrict processing, object to data use, and avoid automated decision-making. These rights, combined with the transparency and accountability measures imposed on organisations, aim to strike a balance between the interests of data subjects and the legitimate needs of businesses and institutions in the digital age. However, despite the comprehensive rights granted to individuals under regulations such as the GDPR, a ‘technological gap’, i.e., a significant lack of efficient tools, for exercising these rights remains [2]. Many organisations struggle to provide accessible, user-friendly mechanisms for individuals to manage their personal data, often relying on cumbersome manual processes, which can lead to delays, or even non-compliance. For data subjects, the process of requesting access, rectification, or deletion of their data can be time-consuming, unclear, and inconsistent across different platforms. Additionally, there is a lack of standardisation in how organisations handle these requests, further complicating the process. Without more automated and streamlined tools, individuals face unnecessary barriers to effectively controlling their data, undermining the intent of regulations designed to empower them.

In this context, we present a specification to express information regarding rights exercise and management in a machine-interpretable format, using semantic Web standards such as RDF. In doing so, we begin to address the automation, interoperability and standardisation challenges identified above, towards enabling the development of tools for assisting individuals and organisations in right exercising activities. Towards achieving this goal, we reuse and extend the Data Privacy Vocabulary (DPV) [3], [4], which allows the expression of information related to legislative requirements such as the GDPR. The developed extension provides a taxonomy to enable representing justifications associated with the non-fulfilment, non-requirement, delays, and exercising of processes, including rights exercising. Beyond DPV, the contributions in this article also promote the usage of the Open Digital Rights Language (ODRL) [5], Data Catalog (DCAT) [6], DCMI Metadata [7], and provenance (PROV) [8] ontologies to express information about: (1) Linking personal data processing activities to applicable rights, (2) Providing notices related to said rights, (3) Documenting the exercise of rights, and (4) GDPR rights requests. The resulting specification is being developed in the context of the W3C Data Privacy Vocabularies and Controls Community Group (DPVCG).

The remaining of the article is structured as follows: Section 2 provides background information on GDPR’s data subject rights and existing semantic technologies for rights management, Section 3 presents the developed specification to express applicable rights, notices, records of activities and rights requests, and Section 4 concludes and presents future directions of work.

Background and State of the Art

GDPR’s data subject rights are provided on Chapter III, with Articles 12 and 23 listing requirements for and exceptions to the exercising of rights, respectively, and with Articles 13 to 22 concretely defining them. Rights can be passive, i.e., no action needed from the data subject for them to be applicable, or active, i.e., need to be actively requested by the data subject. Nonetheless, in both cases, they involve the flow of information between a data subject and a data controller. After confirming receipt of the data subject’s request, the controller must verify the identity of the data subject before proceeding with the request. If the controller is unable to identify the data subject, additional information must be provided by the data subject to enable identification. If the controller has a valid justification for not fulfilling the right, the data subject must be informed of such justification. In cases where the request is complex or there are a large number of requests, the controller is granted a 2-month extension to fulfill the request. Additionally, if the request is deemed unfounded or excessive, the controller may charge a fee, and the data subject will only receive the requested information once this fee is paid. If the controller fails to meet its obligations at any point, a GDPR breach occurs. The European Data Protection Board (EDPB) also endorsed and issued guidelines to assist on data subject rights [9]–[11].

Even though the existence of these rights has been brought forward has a huge step for individuals empowerment over their personal data, no standards have been defined for the management of information related to rights exercising. An exception to this statement might be the ‘Data Rights Protocol’¹, developed by Consumer Reports Innovation Lab², which “defines a web protocol encoding a set of standardized request/response data flows such that Users can exercise Personal Data Rights provided under regulations like the California Consumer Privacy Act, General Data Protection Regulation, and other regulatory or voluntary bases, and receive affirmative responses in standardized formats”³. It does not however cover all GDPR rights and does not promote the usage of standard vocabularies to record information about rights being exercised. Since semantic technologies promote interoperability, allowing information and its interpretability to be consistently defined across different platforms, improving the discoverability, management, and preservation of resources, we will promote the usage of semantic Web standards for the definition of a specification to express rights exercisement and management. As such, DPV⁴[3], [4] is the main driver of the specification presented in this work, as it is the most comprehensive data protection-related vocabulary, providing a set of taxonomies for the expression of metadata related to the usage of personal data aligned with legal requirements, e.g., the GDPR. Additionally, the usage of ODRL⁵[5], DCAT⁶[6], and PROV-O⁷[8], which are Web standards developed and maintained by the W3C, is also promoted to express information about policies, catalogs of resources and activity provenance information, respectively. The DCMI Metadata Terms standard⁸[7], recommended to be used for metadata-keeping by other other Web standards, including ODRL and DCAT, is also reused.

Rights Exercise and Management

Based on the GDPR provisions for data subject rights identified in Section 2, the following requirements are addressed in the proposed specification:

The work is publicly available⁹ and includes examples for each requirement identified above, which are omitted from this article due to size restrictions.

Applicable Data Subject Rights

Beyond jurisdiction-dependence, applicable data subject rights also depend on the legal ground used to process personal data. In the case of the GDPR, DPV’s GDPR extension¹⁰ contains the terms to represent the rights available under GDPR, as well as a mapping of which rights are applicable based on the used legal basis. As such, apart from detailing information about what personal data is being processed, how, where, by whom, and for what purpose, a dpv:Process can also be used to indicate applicable rights. Data controllers can use this approach to express which rights apply, including those beyond GDPR, such as the EU’s fundamental rights and rights outlined in other EU regulations or jurisdictions, i.e., the dpv:hasScope property can be used to indicate applicable rights by jurisdiction. Listing [lst:rights] highlights the modeling of a personal data process using DPV, where dpv:hasScope is used to express existing rights under EU’s GDPR when data is processed based on consent and its similar UK-based counterpart.

ex:ProcessEmailForServiceProvision a dpv:Process ;
    dpv:hasDataController ex:DataController ;
    dpv:hasPersonalData pd:EmailAddress ;
    dpv:hasProcessing dpv:Use ;
    dpv:hasPurpose dpv:ServiceProvision ;
    dpv:hasScope [
        dpv:hasLegalBasis eu-gdpr:A6-1-a ;
        dpv:hasJurisdiction loc:EU ;
        dpv:hasApplicableLaw legal-eu:law-GDPR ;
        dpv:hasRight eu-gdpr:A7-3, eu-gdpr:A13, eu-gdpr:A14, eu-gdpr:A15, eu-gdpr:A16, 
            eu-gdpr:A17, eu-gdpr:A18, eu-gdpr:A20, eu-gdpr:A22, eu-gdpr:A77 ] ;
    dpv:hasScope [
        dpv:hasLegalBasis ex:GB-GDPR-consent ;
        dpv:hasJurisdiction loc:GB ;
        dpv:hasApplicableLaw legal-gb:law-GDPR, legal-gb:law-DPA ;
        dpv:hasRight ex:RightOfAccess ] . # not complete, other rights exist

ex:DataController a dpv:DataController .

ex:RightOfAccess a dpv:Right ; skos:broader dpv:DataSubjectRight ;
    dcterms:description "Right of access to personal data" ;
    dpv:hasApplicableLaw legal-gb:law-GDPR .

ex:GB-GDPR-consent a dpv:LegalBasis ; skos:broader dpv:Consent ;
    dcterms:description "Consent given by the data subject" ;
    dpv:hasApplicableLaw legal-gb:law-GDPR .

Justifications for the exercising of rights

As a result of the collection of requirements for GDPR rights exercising, a Justification taxonomy¹¹, to provide reasons or explanations related to the fulfilment, non-fulfilment, delay and exercise of rights, was developed. Examples of justifications include individual’s identity not being verifiable or a request being considered overly excessive or burdensome. Justifications can also explain why certain processes are necessary or being delayed, such as the ground to exercise the right to object or requiring additional information to move forward with a process. To facilitate the expression of these detailed justifications, this extension introduces concepts that extend DPV’s Justification concept. Moreover, since such concepts can be reused for other data protection-related activities, e.g., data breach reports, the concepts were defined in a generic way so that they can be reused in distinct contexts.

Notices related to the fulfilment or non-fulfilment of rights

Right exercise notices should inform data subjects about where and how to exercise an active right, what information is needed, or provide updates on a submitted right request. DPV’s isExercisedAt property can be used to link rights to specific exercise points, such as through right exercise notices, and to connect the required information with a process using DPV’s hasProcess property. DPV’s hasRecipient, hasStatus, and hasJustification properties can be employed to update the data subject on the status of their right exercising activity, including any justification for why the right is being exercised. In addition to the properties mentioned earlier, DCMI’s concepts can be reused to indicate temporal and other metadata information related to notices. Table 1 summarises the terms reused from DCMI throughout this specification. The notices should also provide information about the data controller, as well as the entity responsible for implementing the notice. This could be the data controller or another entity acting on their behalf, represented using dpv:hasDataController and dpv:isImplementedByEntity, respectively. Additionally, foaf:page¹² can be used to reference a document, such as a Webpage, that contains the full details of the notice and offers further functionalities.

Notices specifically informing about the fulfilment, progress toward fulfilment, or non-fulfilment of a right can also be modelled with DPV. Actions required by entities to fulfil a rights-related request, which cannot be fully detailed using DPV– such as issuing payment terms –can be attached to these notices, e.g., using ODRL policies. Listing [lst:notice] provides an example of a non-fulfilment notice, where the request will be unfulfilled, since it would interfere with the right of freedom of expression and information of others, as indicated by the FreedomOfExpressionImpaired justification. For GDPR-specific notices, DPV’s GDPR extension offers concepts for both direct and indirect data collection notices, as required by Articles 13 and 14, respectively, and it also includes Subject Access Request (SAR) notices to fulfil the GDPR Right of Access, and recipient notices to meet the notification requirements of Article 19.

ex:RejectRightToErasure a dpv:RightNonFulfilmentNotice ;
    dcterms:issued "2024-09-06"^^xsd:date ;
    dcterms:description "Notice of non-fulfillment related to an exercised right to erasure" ;
    dcterms:identifier "x4ghyun-658393" ;
    dcterms:language "EN" ;
    dcterms:publisher ex:DataController ;
    dpv:hasRight eu-gdpr:A17 ;
    dpv:hasDataController ex:DataController ;
    dpv:isImplementedByEntity ex:DataController ;
    foaf:page <https://example.org/DataController/RejectRightToErasure> ;
    dpv:hasRecipient ex:DataSubject ;
    dpv:hasStatus dpv:RequestUnfulfilled ;
    dpv:hasJustification justifications:FreedomOfExpressionImpaired .

ex:DataSubject a dpv:DataSubject .

Records of rights-related activities

Recording provenance information when a specific instance of a right has been or is being exercised is valuable for data controllers, as it provides machine-readable information about the status and fulfilment of requests, which can be useful for auditors, among others. To represent specific records of rights being exercised, DPV’s RightExerciseRecord can be used to link a particular request, or multiple requests from the same data subject, with the corresponding activities, i.e., dpv:RightExerciseActivity, carried out by entities to fulfil those requests. Right exercise records can also leverage the DCAT standard for representing data catalogues. A right exercise record can be modelled as a dcat:Catalog, with right exercise activities represented as dcat:Resource, which can be grouped and organised using dcat:DatasetSeries. This approach offers the advantage of utilising DCAT’s ordering properties, such as dcat:first, dcat:last, and dcat:prev, to easily track and retrieve the most recent activity related to a specific rights-related request. Listing [lst:record] provides an example of a right exercise record maintained by a data controller for all the rights-related requests of a particular data subject. A catalogue record, i.e., dcat:CatalogRecord, is maintained to capture metadata about the right exercise record, including details about the data controller and the data subject. In the example, the data subject has initiated two requests, ex:request-001 and ex:request-002. The right exercising activities related to these requests are grouped and organised in ex:request-001-series and ex:request-002-series, respectively. Using the dcat:last property, the most recent activity for each request can be easily retrieved.

ex:catalog-001 a dpv:RightExerciseRecord, dcat:Catalog ;
    dcterms:description "Record maintained by the data controller for a data subject's rights-related requests" ;
    dcterms:publisher ex:DataController ;
    dcterms:created "2023-10-23T08:37:25"^^xsd:dateTime ;
    dcterms:modified "2023-11-03T08:37:25"^^xsd:dateTime ;
    dcat:record ex:DS-record ;
    dcat:catalog ex:request-001, ex:request-002 .

ex:record-001 a dcat:CatalogRecord ;
    dcterms:description "Metadata about catalog-001" ;
    foaf:primaryTopic ex:DataSubject ;
    dcterms:publisher ex:DataController ;
    dpv:hasDataController ex:DataController ;
    dpv:hasDataSubject ex:DataSubject ;
    dcterms:issued "2023-10-23T08:37:25"^^xsd:dateTime .

ex:request-001 a dpv:RightExerciseRecord, dcat:Catalog ;
    dcterms:description "Record maintained by the data controller for a GDPR Art.15 request" ;
    dcterms:created "2023-10-23T08:37:25"^^xsd:dateTime ;
    dcterms:modified "2023-10-25T08:37:25"^^xsd:dateTime ;
    dpv:hasRight eu-gdpr:A15 ;
    dpv:hasStatus dpv:RequestFulfilled ;
    dcat:resource ex:SARequest, ex:SARAcknowledged, ex:SARRejected, ex:SARRequiresAction, 
        ex:SARActionDelayed, ex:SARActionPerformed, ex:SARAccepted, ex:SARFulfilled .

ex:request-001-series a dcat:DatasetSeries ;
    dcat:first ex:SARequest ; dcat:last ex:SARFulfilled .

ex:SARAcknowledged a dpv:RightExerciseActivity, dcat:Resource ;
    dcat:inSeries ex:request-001-series ; dcat:prev ex:SARequest .

In this context, a dpv:RightExerciseActivity represents a specific instance of an activity carried out in the process of exercising a right. These activity instances should include metadata, such as timestamps, duration, and involved entities, to track the provenance of the right exercising process – from the initial request to its acknowledgement by the data controller, and ultimately to the fulfilment or non-fulfilment of the right. To track the status of rights exercising activities, DPV provides RequestStatus concepts, such as RequestAccepted for accepted requests moving toward fulfilment or RequestRequiresAction for requests requiring further action from another party. Figure 1 illustrates the lifecycle of these concepts. Once a request is initiated, it should be acknowledged by the responsible entity and either accepted for fulfilment or rejected. If rejected, the entity may require additional actions from the requester (e.g., providing more information to proceed), which can delay the acceptance or rejection. After the required action is taken, the request may either be accepted for fulfilment, rejected again, or further action may be requested.

Moreover, DPV concepts can be combined with the W3C’s PROV-O recommendation to track the provenance of a right exercising activity instance. This allows for the representation of provenance details, such as the entities involved in the activity, i.e., prov:wasAssociatedWith, or the data/notice generated by the activity, i.e., prov:generated. The prov:actedOnBehalfOf property can also be used to represent delegation or representation, for example, when a parent exercises a right on behalf of a child. Listing [lst:activity] provides an example of an activity where the data controller requires further action from the data subject to be able to proceed with the request. The required action is defined using a dpv:Process. Examples for the whole lifecycle of activities are provided in the proposed specification. Furthermore, the proposed model for right exercising activities is generic enough to support the representation of rights from other jurisdictions and can be easily extended if the need arises.

ex:SARRequiresAction a dpv:RightExerciseActivity, prov:Activity ;
    dcterms:description "Data controller requires further action from data subject" ;
    dcterms:created "2023-11-02T16:09:21"^^xsd:dateTime ;
    prov:wasAssociatedWith ex:DataController ;
    dpv:hasDataSubject ex:DataSubject ;
    dpv:hasStatus dpv:RequestRequiresAction ;
    dpv:hasJustification justifications:IdentityVerificationFailure ;
    dpv:hasProcess [
        dpv:hasPersonalData pd:OfficialID ;
        dpv:hasProcessing dpv:MakeAvailable ;
        dpv:hasPurpose dpv:IdentityVerification ;
        dpv:hasRecipientDataController ex:DataController ;
        dpv:isImplementedByEntity ex:DataSubject ] .

GDPR-related rights requests as machine-executable policies

DPV and ODRL can also be used for data subjects to send GDPR-related right requests in a machine-interpretable format to data controllers. Such requests can then be integrated in their rights management processes to for automated execution of responses to data subjects’ requests. For example, systems that use an ODRL evaluator based on the formal semantics of ODRL [12] can assess policies to determine which ones are active, have been violated, or have been fulfilled, to respond consistently and interoperably to rights-related requests. As such, GDPR’s data subject rights described in Articles 15 to 22 can be instantiated as ODRL policies containing permissions, prohibitions and obligations to data controllers to act upon or fulfil. Generic policies for each right are available in the proposed specification. Listing [lst:policy] provides an example of a request to exercise GDPR’s right to erasure. It can be represented as an obligation to delete a data subject’s personal data based on one of the grounds specified in Article 17.1. These grounds can be detailed using DPV’s justifications, e.g., the data is no longer necessary in relation to the purposes for which it was processed –justifications:NonNecessityObjection. Additionally, Article 19 requires that if the data has been shared with recipients, the data controller must inform the data subject about these recipients.

ex:delete-request a odrl:Request ;
    odrl:uid "3456-7890-1234-5678-9012"^^xsd:string ;
    dcterms:description "Data subject requests data controller to delete their data." ;
    odrl:obligation ex:DS-delete-data ;
    odrl:obligation ex:DS-delete-notice .

ex:DS-delete-data a odrl:Duty ;
    dpv:hasRight eu-gdpr:A17 ;
    odrl:target ex:DS-data ;
    odrl:assigner ex:DataSubject ;
    odrl:assignee ex:DataController ;
    odrl:action odrl:delete ;
    odrl:constraint ex:DS-delete-justification .

ex:DS-delete-justification a odrl:Constraint ;
    odrl:leftOperand dpv:Justification ;
    odrl:operator odrl:eq ;
    odrl:rightOperand justifications:NonNecessityObjection .

ex:DS-delete-notice a odrl:Duty ;
    dpv:hasRight eu-gdpr:A19 ;
    odrl:action odrl:inform ;
    odrl:informedParty ex:DataSubject ;
    odrl:informingParty ex:DataController ;
    odrl:target ex:DS-RightsRecipientsNotice .

ex:DS-RightsRecipientsNotice a eu-gdpr:RightsRecipientsNotice .

Conclusions and Future Work

This article provides a machine-interpretable and executable model to represent information regarding data subject rights, concepts to justify their fulfilment or non-fulfilment, notices to communicate about them with other entities, records for auditing and policies for automated execution of responses to rights requests based on the GDPR. Through these, we hope to enable related tools and processes to handle obligations related to rights in an interoperable manner.

We believe our proposal provides a crucially missing technological piece that is required to make effective use of GDPR rights across different services and devices that utilise the Web. The Data Privacy Vocabulary (DPV), which is a central component of our rights management specification, is a comprehensive and growing resource that is being actively developed, has been used by industry and academic projects, and involves inputs from a diverse range of stakeholders. More importantly, the development of DPV – and the rights management concepts presented here – involves engagement with legal experts who validate its use as per legal requirements under GDPR, and discussions with Data Protection Officers¹³ and implement legal compliance platforms¹⁴ who provide practical grounding for ensuring this work is effective.

To realise the potential of our work, it is important for the rights management specification to be seen as useful and effective by organisations and legal authorities so as to enable its uptake. To enable its technical adoption, one option is to integrate this work with protocols such as the Data Rights Protocol which creates a single consistent technical signalling mechanism for rights management on the Web. Another option is to utilise existing EU-friendly mechanisms such as the Advanced Data Protection Control¹⁵ (ADPC), which have rights management in their scope but lack the technical implementation – which this work can provide.

Finally, we highlight the importance of this work in developing ecosystems based on the Data Governance Act (DGA), Data Act, and the Data Spaces regulations, where data reuse will be based on technical infrastructures. Additionally, the EU Commission has launched an ambitious program¹⁶ consisting of creating a secure European Digital Identity wallet (EUDI) which will be used by individuals and organisations to assert their identity and access public/private services based on personal data stored in the wallets. While work on how to store and manage consent in such wallets based on standards has already been explored [13], the question of how such wallets can facilitate rights exercise has not been explored. The work presented in this article provides the technical basis for creating a GDPR-compliant by design rights management infrastructure that Data Spaces or EUDI wallets can utilise for individuals and organisations to exercise and manage rights in a consistent standardised and interoperable manner. This not only facilitates GDPR compliance, but also creates a streamlined experience for users and promotes transparency and accountability.

Funding Acknowledgements This project has received funding from the EU’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 813497 (PROTECT ITN). Beatriz Esteves is funded by SolidLab Vlaanderen (Flemish Government, EWI and RRF project VV023/10). The ADAPT Research Centre for AI-Driven Digital Content Technology is funded by Science Foundation Ireland (SFI) under Grant#13/RC/2106_P2.

References