Categorisation of Entities

For entities and the interoperability between them, we use the following abbreviations or denominations. A Data Subject (DS) is an individual or entity in the context of personal data. They are the user or recipient of a system or a service, and provide the consent for activities. Data Controller(s) or ‘Controller’ (DC) is an entity that determines the purposes and means of the processing of personal data. They can act jointly, in which case they are called Joint Controllers. A Data Processor (DP) is an entity that processes personal data on behalf of the controller. The relationship between controllers and processors is many-to-many, i.e. either can be associated with multiple entities of the other type. A sub-processor is a processor acting under another processor. They are bound by the same rules of agreement as the processor they are under with its controller. The Supervisory Authority (SA) or Data Protection Authority (DPA) is a public institution responsible for monitoring the application of data protection laws. These are the entities we consider to be within the scope of this paper. In addition, there are other entities mentioned in the GDPR such as - Representative of Controller, Processor, Data Subject, as well as the Regulatory Authority, and Certification Bodies.

Interoperability between Entities

There are several possible cases of interoperability between these entities as reflected by the model in . In this, each point of interaction between two entities is considered to be a point for interoperability between the two entities. Taking the entities under consideration as DS, DC, DP, and SA, we have a set of 6 possible points for interoperability without considering the direction of interaction. Additionally, since controllers and processors can interact with other controllers and processors respectively, and supervisory authorities can interact with other supervisory authorities, this brings the total count of possible points to 9. These are shown in the figure as well as listed in . along with examples of information associated between the two entities.

The entities depicted in the model are taken from the text of the GDPR. Since only the type of entity is required for understanding and modelling the interaction, their size (large, medium, small, or individual) or nature (commercial, governmental, or not-for-profit) has no bearing on the interoperability point. Additional information may need to be exchanged based on specific requirements, though this requires a deeper review of the law and clarification through legal experts. We therefore do not consider such additional requirements to be within the scope of this paper. For entities such as governmental institutions and organisations that are in a position where information communication needs to be made available for dissemination to the public, we consider this as motivation to explore the requirements of sharing such data in an ‘open’ and ‘consistent’ manner. Where entities are commercial entities, interoperability is more concerned with consistency, structure, and correctness of information being exchanged.

Consider the interactions between Data Subjects and Data Controllers or Data Controllers and Data Processors, where the interoperability requires only that the provider and consumer or recipient merely provide the required information in an agreed format. This information is not inherently intended to be made available to anyone else (other entity), and therefore has no bound requirements in terms of standards at this point of interaction. Contrast this with the case where the Supervisor Authority, a public institution is involved. Communication with Data Controllers and Data Processors would have to take into consideration the sensitivity of private information and therefore would require the use of secure forms of communications which may also require security in the information structuring itself, such as through encryption or establishment of secure channels. Any warning or ruling by the SA that can be considered public information, as in made available to the public, would need to be also published in an appropriate manner. The current norm for this is for the SA to publish details of use-cases along with their rulings or decisions on its website. Such information in the future might be collated in a registry or dataset using appropriate formats and structuring.

The interaction between Data Subjects and Data Controllers is one of the major points of concern addressed by the GDPR. The interoperability between these entities involves the DS providing personal data to DC, which will be in whatever form the DC offers to accept. However, DS also provide consent to the DC, which needs to follow certain guidelines stipulated by the GDPR regarding compliance which can affect the way consent is collected and stored. Though this puts no restriction on how the DC obtains this consent from the DS, the onus is on the DC to ensure that the obtained consent satisfied the obligations of the GDPR for demonstrating the validity of such consent. Therefore, it would be prudent for DC to obtain or convert the consent in a form that makes this process of compliance easier.

The interaction from DC to DS includes the provision of information regarding services and rights as mandated by GDPR. DC also has to provide information for rights such as right to data portability which allows DS to receive a copy of their personal data upon request. GDPR has particular clauses regarding the provision of this data, and its structure or format. Additionally, GDPR also provides for DS to get their personal data transferred from one DC to another, which requires both controllers should have some form of interoperability mechanism to send as well as accept the data in a manner that is mutually understandable.

For interactions between DC and DP, or DC and DC, or DP and DP, these points already have some interoperability as part of an organisation’s business practice. However, under GDPR, certain additional information may need to be shared in the operation of such services. This provides an opportunity for exploring whether a structured or a common format might provide advantages to existing practices. An approach suggesting an entirely new form of interoperability model would be difficult to uptake due to existing infrastructures. Alternatively, an approach that only considers the information necessary for compliance can be proposed as a solution that augments existing services rather than replaces them.

Interoperability as part of GDPR compliance is primarily outlined by the interactions between the Supervisory Authority and Controllers/Processors. The compliance information reflects the data required to demonstrate and determine the organisation’s compliance, which legally can be in any form as long as it contains the correct and sufficient information. For organisations, the process of maintaining, sharing, and demonstrating compliance using this information is a challenge that warrants looking at alternate approaches that can help with these activities. One avenue of possibility is provided in the case where this information is linked to information such as those related to processing activities that are also involved in compliance. Taking advantage of this relation, one can use a structured approach that provides an efficient and effective way for the storage, management, and querying of such related information.

Categorising Information Flows

For the current paper, we only consider certain information categories and explore them in more detail. These are - provenance, agreements, consent, certification, and compliance. The entities and interactions involving these information categories are listed out in . which describes the information associated with each information category and the entities involved.

Provenance

The provenance information category, as defined by provenance, refers to information about entities and activities involved in producing some data or artefact, which can be used to form assessments about its quality, reliability or trustworthiness. This information is related to the compliance for activities that involve some data that needs to be linked or resolved to the activities that create, use, share, or store it. An example of this is that of consent along with the activities associated with it that obtain, update, or invalidate the consent. For demonstrating compliance, it is essential to show that these activities functioned correctly, which requires the presence and maintenance of logs that record the functioning of these activities. These logs can be modelled as provenance in which case they form the lifecycle of consent tracking its creation (obtaining), use within different activities, how it is stored, and finally its deletion (invalidation). Compliance then becomes a matter of introspection such provenance logs to see whether the activities recorded the correct and compliant behaviour. A deeper example is that of checking whether a consent was validly given, which requires that the consent be freely given, specific, and unambiguous. Since detecting is not possible without manual oversight, the artefacts and processes involved in the obtaining of provenance can be useful in capturing the state of things as present when obtaining the specific consent. Depending on the manner of representing provenance, the lifecycle of consent can then be traced with sufficient granularity and abstraction to link it with activities that depend on it, thereby making it possible to also determine whether the consent was used as intended by the terms of the GDPR.

As provenance information potentially encompasses all artefacts and processes requiring compliance, it can be argued that having interoperability with relation to sharing and evaluating provenance information would greatly benefit the compliance operations for both the organisation as well as the authorities. Additionally, as compliance itself involves several activities and the creation of artefacts such as compliance reports, this information can also be defined using a common provenance format for reuse and dissemination. Such forms of interoperability can be used in any interactions where provenance information needs to be shared or evaluated, such as is also the case with controllers and processors where there is a need to define activities that need to take place, or to maintain a joint or collaborative record of activities undertaken that involve both entities. This is especially useful when information needs to be shared that involves lifecyles of artefacts such as consent and personal data need to be tracked or charted across activities. Provenance defined in such manner has led to approaches in the existing corpora of work to create a privacy impact assessment template . and creating components based on activities .

Data Sharing Agreements

The next category of information we consider is that involving agreements between entities such as that between DC and DP, or DC and DC, or DP and DP. The form of agreements needs to take into consideration that they can change depending on factors such as change in consent and rights being exercised. Therefore, exploring the use of smart agreements . that can be interacted with in an automated manner to certain extent would benefit systems where a large part of the system operates on a similar level of automation. For example, if a controller receives an instruction from a data subject to update their consent for certain activities which are handled by a processor, the controller must update or enforce (depending on the legal term in use here) their agreement to get the processor to also reflect this consent over the personal data and activities that they have/had received from the controller. Without some form of automation, such requests would need to be sent and received manually, greatly increasing the work and time required to handle them. With automation involved in the process, the controller’s system can automatically take care of the request by updating the agreement in place for handling the particular consent and personal data with the processor, and can also await for a receipt from the processor for successful completion of the request. Such agreements that can be iterated, stored, and queried using systems are of benefit to the involved parties as well as other entities that might wish to introspect the agreements such as certification bodies and regulatory authorities. An example of this is data sharing agreements that can be explicitly designed to be interoperable based on requirements of the GDPR .

Consent

Consent in the context of the GDPR refers to the assent or agreement by the data subject in relation to their personal data for the proposed processing activities associated with one or more entities. Given consent refers specifically to the form of consent given by the data subject in relation to their personal data and the proposed usage by activities . Consent can be considered to be an agreement between the data subject and the data controller (or other entity), and can therefore benefit from the same approach for implementing the data sharing agreements. This provides consistency in technology as well as encourages adoption of uniform standards and interoperability in dealing with similar use-cases.

GDPR specifies certain requirements which guide the acquisition and demonstration of consent for it to be deemed to be valid . These include the stipulation that consent must be freely given, must be informed, specific, and voluntary. Of these, only the specificity of consent can be gauged from a given consent in a form such as an agreement. Given consent contains the terms which have been accepted by the user, which can be used to gauge the specificity of the agreement, and therefore decide on whether the consent itself was specific or broad under the GDPR. For other stipulations related to valid consent, it is essential to refer to the process and artefacts used to acquire the consent to understand the conditions under which the consent agreement was provided to the data subject and how it was accepted or given or agreed.

For example, in cases where the consent is acquired through a web-form , the entire web-page may need to be preserved to demonstrate that the consent acquisition process was in accordance with the conditions under the GDPR. Therefore, while the given consent may be represented in any form, it also has to somehow be linked to the processes responsible for acquiring the consent. Additionally, any revision of consent data such as when updating or revoking consent also needs to be stored in a way that can be linked to the processes involved in the change as well as linked to the original consent. This is important as a matter of compliance as GDPR enforcement may require demonstration that a change in consent was carried out correctly, which is only possible through an introspection of what the original and changed versions of the consent are. This also introduces the dependency-like relation between data processes and consent where consent should be inherently linked to the processes that depend on it. For example, if the process of using personal data to send emails is dependant on the consent obtained from the user at the time of registration, then it is vital to show that the two are linked together, i.e. the emails are only sent based on the given consent. Such a system must also be able to demonstrate that updated consent has immediate effect on the processes that depend on consent.

These requirements show the inherent dependency of consent and personal data along with the processes involved which presents a strong argument for representing them together using the same method of provenance. Such a method capturing the various stages of consent and personal data as lifecycles involving processes and artefacts would enable documentation representing the model of the system as a whole. The individual records or logs of activities can then be instantiated based on the model to capture user or event specific information.

Compliance

Overseeing the compliance is an ongoing and continuous process and is specified within the GDPR as an activity to be undertaken by an organisation at certain times. While the interpretation of the law may vary, it is clear that a responsible entity should ensure that all its activities are compliant at all stages of operation. This can be achieved by having proper practices and processes regarding evaluation of compliance from the design stage at the earliest. Such processes ensure that a new service or change in an existing service are compliant before they begin the operation. Several people might be involved in design and operation of the system, but the responsibility of ensuring the compliance falls on the management or on Data Protection Officer (DPO) if appointed. In any case, such checks of compliance are integral to audits by the organisation itself or a third-party hired by the organisation for ensuring proper legal requirements are met by their activities. A record of such activities and its outcome is therefore an essential outcome of such audits or compliance processes and forms part of the compliance information maintained by the organisation. Such information would prove to be helpful for supervisory authorities who might wish to inspect the activities of an organisation and determine responsibility in cases where multiple entities are involved.

Such information of compliance related activities can be represented as provenance though the processes and artefacts involved in this case are different from those related to the consent and personal data lifecycles. To a certain extent, depending on the structuring of compliance activities, it is possible to consider the compliance related activities as part of a compliance lifecycle where the outputs of activities such as various reports can be mapped along a timeline using provenance methods similar to those previously outlined. There might be additional requirements of ensuring the security and integrity of such records, though this probably would not have any bearing on the depiction of the information itself. Instead, any concerns related to the data being tampered or accessed without proper authorisation can be mitigated through proper storage and handling of this information. This also allows the provenance representation required for compliance lifecycles to be consistent in its purported use-case with those related to provenance of consent and personal data lifecycles.

Certifications

GDPR has provisions for seals and certifications which can help organisations with a measure of compliance as well as good practices. These have a maximum validity of three years and have certain conditions or criterion for the creation and issuing of seals and certifications pertaining to GDPR compliance. The seal or certification does not reduce or impact the responsibility of the controller or processor for compliance with the GDPR, but acts as a method of displaying or providing information regarding compliance. The exact nature of such seals and certifications and their role with respect of demonstration of compliance to the authorities is still under consideration.

An existing example of such a mechanism is EuroPriSe (European Privacy Seal, n.d.) which carries out an audit of an organisation before providing a seal which is accompanied by a public report published on its website describing the process. The document describes the processes and their compliance with respect to GDPR obligations. While the document itself may be sufficient to demonstrate certain facts regarding the organisation’s processes, the fact that it is not published in a format that can be reused by the organisation restricts its usage. The organisation who was the subject of the report has only the option to refer to the report through a legal form of citation.

There are several areas of interest where the information included in the report can be structured for representation in a manner that makes it easy to store, access, query, and most importantly share with other entities. For example, if a certain process is responsible for sharing personal data between a controller and a processor, where the processor’s processes for handling the said data have been audited through a report, then this information may prove to be sufficient for an agreement between the two entities. However, any such audit and its accompanying report having a validity of a maximum three years requires the controller and processor to investigate their respective agreements at the end of this report. Agreements therefore needs to consider this process as a requirement which hinders the automatic resolution of agreements between the two parties. One way to mitigate this is to keep this requirement out of the automation, in which case the agreements would continue to operate even when the report validity has lapsed. Another case is where processes change and the processor must renew its certification. If it is able to demonstrate the changes in its processes, the reports can possibly be linked to the version or iteration of process it evaluated, thereby also providing a way for agreements to view and use this information. Even without use in automated agreements, the structuring of such information may provide a strong use within the organisation of compliance related information by cross-linking or cross-referencing the information in documentation that can be continuously updated.

W3C Standards

In this section, we explore existing standards and their suitability towards interoperability of information specific to the requirements set forth in the previous analysis of the GDPR. We consider all approaches - including research and academia, commercial, bodies involved in maintaining standards - with the caveat of the standard being open and non-proprietary. We argue that the use of such open standards fosters better community participation and adoption. For the scope of this paper, we restrict our exploration of standards to those published by the World Wide Web Consortium (W3C) as it is the main standards body responsible for information exchange on the internet. As the exchange of information is most likely supported and occurs through the medium of the web, these standards can be readily integrated into mediums such as websites and web services which form the backbone of interoperability for many organisations, both commercial as well as public institutions.

W3C standards undergo various stages of development starting from Working Draft (WD) to Candidate Recommendation (CR) which are then moved to the Proposed Recommendation (PR) stage before being set as a W3C Recommendation (REC). It is usually considered that standards at stages PR and REC are sufficiently matured to be adopted into usage as they rarely have any significant changes. We therefore consider only those standards which fall in either stages as being suitable for recommendation in this paper.

For representing provenance, we have the Provenance Data Model i.e. PROV-DM , which is a W3C recommendation since 30th April 2013 and provides definitions for interchange of provenance information. Using PROV, we can define entities and the various relations and operations between them such as generated by, derived from, and attributions. PROV has been successfully utilised in several domains and applications including encapsulation of scientific workflows and provenance repositories. PROV was designed to be generic and domain independent, and needs to be extended to address the requirements to represent workflow templates and executions. There are existing approaches in academia that utilise PROV in approaches specific to the representation of provenance information related to GDPR .

The Open Digital Rights Language, abbreviated as ODRL , is a proposed recommendation policy expression language that provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for representing statements about the usage of content and services. The ODRL Information Model describes the underlying concepts, entities, and relationships that form the foundational basis for the semantics of the ODRL policies. Policies are used to represent permitted and prohibited actions over a certain asset, as well as the obligations required to be meet by stakeholders. In addition, policies may be limited by constraints (e.g., temporal or spatial constraints) and duties (e.g. payments) may be imposed on permissions. ODRL can be utilised for representing agreements, which can include both data sharing agreements as well as the representation of consent.

For representing the information itself, W3C has several standards with regards to the structuring and organisation of information such as RDF and OWL along with data formats such as XML. For querying information, there are mechanisms such as SPARQL and XQuery/XPath that operate on standardised forms of data (RDF and XML respectively). For validating the structure of information, Shapes Constraint Language (SHACL) can be used as a standardised form for validating RDF. There are approaches based on commonly utilised formats such as CSV on Web for CSV and JSON-LD for JSON that combine the understandability of such formats with the standardised representation of information such as that in RDF. Reusing such standards provides a form of interoperability in the form of underlying technology utilised to create, store, and query the information. Therefore, any additional standards or formats developed for application-specific approaches should be based on existing forms of standards in order to take advantage of existing practices and adoption of technologies. This line of argument is line with the recent uptake of open-data publishing by the European Publications Office using mechanisms based on RDF and open data formats. Additionally, these existing standards can be used to provide data related to the right of data portability accorded by the GDPR that requires organisations to provide a copy of personal data in a format that is structured, commonly used and machine-readable.

CEN / CENELEC / ETSI

The European Committee for Standardization (CEN) is a public standards organization consisting of thirty four national members that work together to develop European Standards (ENs) in various sectors. CEN is officially recognised as a European standards body by the European Union. The other official European standards bodies are the European Committee for Electrotechnical Standardization (CENELEC) and the European Telecommunications Standards Institute (ETSI). Together, these standardisation bodies provide a large framework of interoperable standards that aim to foster free trade and public benefit. Previously, there was a significant overlap and between the CEN and ISO standards, with some of them presenting potentially conflicting resolutions. This was rectified by the Vienna Agreement where CEN and ISO agreed to avoid duplication of standards. This has resulted in CEN adopting a number of ISO standards which have superseded or replaced existing CEN standards.

ISA²

The Interoperability solutions for public administrations, businesses and citizens (ISA²) programme develops and provides digital solutions that enable public administrations, businesses and citizens in Europe to benefit from interoperable cross-border and cross-sector public services. The programme was adopted in November 2015 by the European Parliament and the Council of European Union. ISA² is the follow-up programme to ISA, and aims to ensure interoperability activities are well coordinated at EU level through a structured plan consisting of a revision to the European Interoperability Framework (EIF) and the European Interoperability Strategy (EIS), along with development of the European Interoperability Reference Architecture (EIRA) and European Interoperability Cartography (EIC) solutions.

The effort has produced a set of ‘Core Vocabularies’, maintained by the Semantic Interoperability Community (SEMIC), that provide a simplified, reusable and extensible data model for capturing fundamental characteristics of an entity in a context-neutral fashion. Existing core vocabularies include ways to define attributes for people, public organisations, registered organisations, locations, public services, the criterion and evidence required to be fulfilled by private entities to perform public services, and a public event vocabulary that is currently under development. SEMIC has also developed the DCAT Application Profile (DCAT-AP), based on the DCAT specification, for describing public sector datasets in Europe so as to enable the exchange of descriptions of datasets among data portals. GeoDCAT-AP is an extension of DCAT-AP for describing geospatial datasets, dataset series and services, while StatDCAT-AP aims to deliver specifications and tools that enhance interoperability between descriptions of statistical data sets within the statistical domain and between statistical data and open data portals.