The General Data Protection Regulations (GDPR) imposes greater restrictions on obtaining valid user consents involving the use of personal data. A semantic model of consent can make the concepts of consent explicit, establish a common understanding and enable re-use of consent. Therefore, forming a semantic model of consent will satisfy the GDPR requirements of specificity and unambiguity and is an important step towards ensuring compliance. In this paper, we discuss obtaining an open vocabulary of expressing consent leveraging existing semantic models of provenance, processes, permission and obligations. We also present a reference architecture for the management of data processing according to consent permission. This data management model utilizes the open vocabulary of consent and incorporates the change of context into the data processing activity. By identifying and incorporating changes to the relational context between data controllers and data subjects into the data processing model, it aims to improve the integration of data management across different information systems specifically adhering to the GDPR and helping controllers to demonstrate compliance.
According to the General Data Protection Regulation (GDPR), consent of a data
subject is one of the legitimate basis for processing personal data [
• An open vocabulary for expressing consent by leveraging existing open ontology models to improve the integration of data management across different information systems.
• Providing mapping of consent into machine readable and machine enforceable format.
• Proposing a consent and data management model by taking into account of consent and data lifecycle. Identifying and incorporating the change of context into the data processing model.
The structure of the rest of the paper is as follows: Section 2 describes the key aspects of GDPR, Section 3 describes the consent and data lifecycle, and changes of context. Section 4 describes the consent and data management model. Section 5 narrates the implementation, while Section 6 reveals the related work and Section 7 concludes the paper. 2
Organizations dealing with personal data of EU citizens must ensure that they’re
compliant with the new requirements of the General Data Protection Regulation
(GDPR) before it becomes effective on 2018, which is replacing the EU Data
Protection Directive [
Freely given: Consent is not freely given if the data subject has no genuine and free choice, or is unable to refuse or withdraw consent easily, or there is a "clear imbalance" of power between the controller and the data subject (e.g., between an employer and an employee).
Specific: The request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language.
Informed: Consent must be taken from data subject by informing the nature of processing in an intelligible format, purpose of processing and identify of the controller and information about withdrawing consent.
Unambiguous: Data subject should take clear affirmative action as an indication to acceptance to the proposed processing of personal data. Inactivity, pre-ticked boxes, silence, failure to opt-out, or passive acquiescence do not form a valid consent.
Parental permission: The processing of the personal data of a child (aged below 16) shall be lawful only if the consent is given or authorized by the holder of parental responsibility over the child. Controller is held responsible for verifying such consent.
The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Therefore, the controller should not only provide options to withdraw the consent, but also should ensure data processing accordingly and keep the provenance of data processing to demonstrate the lawfulness of processing. 3
Before describing the model that incorporates interactions of consent, data and context, here we are describing the lifecycle of data and consent, and the change of context. 3.1
Personal data goes through a number of phases [
After data is collected it is transferred to the service provider’s side. Once transferred it is then used. The use of information should be consistent with the purposes for which it was collected and the commitments made to the consumer by the provider. While using data, proper access control should be enforced and data needs to be managed in way that the compliance with the legal requirements can be verified.
Data can be shared with a third party. While sharing data with a third party consent of the data subject needs to be considered, access control mechanism should allow only the authorized party to access the data, while sharing data the location of data where it is going would be an important factor to consider due to compliance requirement. Before sharing personal data some transformation might be necessary, e.g., isolation of sensitive information, ensure anonymity and unlinkability. Data can be stored within the organization. Storage duration, purpose should adhere to the consent and should not be longer than is needed for the consented purpose. While storing, data can be encrypted. It might be difficult to process encrypted data. Other forms of transformation might be used, e.g., isolation of sensitive information, ensure anonymity and unlinkability. Proper access control should be enforced also should consider insider attack.
Data can sometimes be archived. Purpose and duration for that need to be checked against the given consent. Finally, data is destroyed. Data can be destroyed when consent is revoked, or expired. 3.2
Consent goes through different phases in its lifecycle, as shown in Fig. 1. Consent is first collected, then stored and processed for checking compliance with data processing. The GDPR has clearly addressed the right of data subject to withdraw or revoke consent anytime (Art. 7, 17). Consent can also be modified, which is equivalent to revoke a previous consent and re-consent to a new one. The modification can be initiated by the data subject or due to change of context and the controller can resolicit for consent that can lead to modification of the consent. Any change to consent, including revocation, needs to be archived for the duration necessary for verification or provenance purposes, before finally it is destroyed.
Fig. 1 shows the various phases of consent and data lifecycle and their correlation. Lifecycle of data starts only after the phase 3 of lifecycle of consent i.e. the collection of data starts only after the consent is processed to ensure the data collection compliance with the consent. Lifecycle of consent continues after the lifecycle of data finishes, to capture the provenance of consent. Any consent/ data management system should adhere to the lifecycle and their relationship. 3.3
Consent is given for a certain context, for e.g., for a certain service provided by a
certain organization for a certain purpose. The purpose of using data might change
overtime due to adoption of new technology. This change of purpose is a change of
context for which consent was obtained. According to the GDPR when the intended
purpose of data processing changes the controller should provide the data subject with
information on that other purpose and other necessary information. This kind of
context is generated from the provider’s side. Another example for such context can be
occurrence of data breach. Context can also be user generated, such as, modify or
withdraw of data/ consent. Context can be generated from the environment, such as,
expiry of consent or data or detection of other external context change. An example of
external context change can be acquisition of start-ups or merging companies, which
is a quite common occurrence these days [
In this section we describe our proposed consent and data management model. The model concentrates on two objectives:
1. To identify important concepts of consent and their interrelationships as the basis for a homogeneous representation of consent. It aims to make the consent specific, clear and unambiguous.
2. To manage data according to the consent and data lifecycle, while incorporating changes of context in the data processing model. This aims to reduce the cost and improve the efficiency of assessing and demonstrating organizations’ compliance. 4.1
An ontology is commonly defined as: “an explicit specification of a
conceptualization” [
Our Consent Ontology formalizes a generic model for the notion of “consent” by
identifying and describing the important concepts and relations. The basic purpose of
giving consent is providing permission to perform personal data processing for
specified purposes. The ontology should cover the permission-related concepts of consent
such as “who is allowed or denied to do some activity on what data”. Each permission
is granted for a certain time and therefore validity time is also a key part of
permission of consent. A consent can also cover obligations which are the actions to be
performed when certain event, such as change of context, occurs. An example of consent
related obligation can be to renegotiate consent when the purpose of data processing
changes. Since GDPR prescribes that it is the controller’s responsibility to
demonstrate that the consent was validly obtained, the ontology should provide support for
the provenance of consent obtained as well. Therefore, the ontology has concepts of
consenting party and context which includes the time, location, format of gathering
consent and as well as information provided when consent was requested. To
incorporate these concepts in the consent ontology we extended the Provenance Ontology
(PROV-O) a W3C Recommendation. PROV-O allows us to model the provenance of
Entities in terms of the Activities that that generate or process them and the Agents
undertaking those Activities. These provenance concepts are mapped onto the consent
management ontology in Fig. 2. In this way, other extension to PROV-O (e.g., for
planning processes or for specific resource types) and tools that process provenance
data can be used to support the implementation of the consent management system. In
future, we will align it with ODRL Permissions & Obligations Expression (POE).
We stated that our ontology provides a generic model. With “generic”, we mean that
we provide an upper common ontology for consent; one that provides a broad,
reusable coverage that needs to be specialized for specific cases. As the ontology is shared
– i.e., accessible via a URI that is both used as the ontology’s namespaces and
resolves to the ontology document via basic Semantic Web and Linked Data principles.
An upper common ontology provides the abstract concepts and relations that are
shared across by many domains and applications and queries formulated in terms of
those will return meaningful answers for each system. While reusable, the ontology
might not be useable for very specific tasks or domains because of its under
specification. The tension field between generic, reusable ontologies and specific, useable
ontologies is well described in [
The way consent objects are presented and gathered varies from service to service and also due to the use of various devices. The ontology can be used to annotate the relevant concepts in consents that are captured in various formats. A semantically homogeneous representation can be created from these annotations and this is useful in number of ways. Firstly, it helps in getting enforceable rules and provenance information. Secondly, it helps to produce an intelligible and user friendly representation of consent by highlighting the important concepts of consent. Finally, it will further help in the migration of consent from one domain to another while ensuring the enforcement of consent. 4.2
In this section, we present the Consent and Data Management Model (CDMM), an abstract reference architecture, to incorporate the consent permission and change of context into data processing model. It aims to reduce the burden on organisation to assess and demonstrate their compliance. The CDMM, as shown in Fig.3, consists of five components: User Interaction Handler (UIH), Consent Manager (CM), Context Handler (CH), Data Manager (DM) and Provenance Manager (PM).
The UIH is an interface for interacting with the users and is responsible for getting consent, exchanging of required information. It further provides facilities for enforcement of rights, such as, data access, erasure or rectification of data, or requests for portable data. These rights are mandated by the GDPR, are common for all data subjects, and do not depend on individual consent. However, the type of service and the scope of consent influence the implementation and precise scope of the rights. The interface used to handle such rights also should not be significantly different from the data collection interfaces. Therefore, the UIH is delegated the responsibility to handle all user actions through a single, uniform point of access and provides a uniform interface for all the users to enforce those rights.
The permissions that each data subject provides in the form of consent is distinct for each user and needs to be obtained before getting and processing the data. The CM utilizes a consent ontology to translate the obtained consent into usable properties such as consent validity, consent obligation and consent permission. The separation of such consent-based information is designed to ease the processing of consent, due to the differences in how these might be implemented, e.g. validity might just be some constrain check, perhaps done as deontic logic reasoning and queries directly on the owl instances, permission would map onto the XACML system, while obligation might need something different, more like a workflow management system. Consent obligations contain instructions related to consent, including the range of contexts under which a new consent must be sought from the data subject or under which condition the subject needs to be informed. Some other consent obligations are to stop data processing when consent expires, to delete data after a certain period, or when the purpose for which consent was sought will no longer be undertaken, and to inform data subjects whenever a data breach is detected. Consent permission states the processing or activities that are allowed to take place by data subjects on the personal data. The CM only keeps the up-to-dated consent, which is relevant for the current permissions for processing of data. Additional information, such as, who signed the consent, when was the consent given, what information was exchanged while providing consent is stored by the Provenance Manager (PM). The Context Handler (CH) is responsible for managing context and for detecting changes of context and informing the CM and DM of these changes. The DM is responsible for managing data according to the consent and provides protective control by ensuring only authorized processing can occur.
The PM is responsible for maintaining a provenance log of all activities involving data and consent. It tracks the lifecycles of consent and data. From the tracks it is possible to identify the source, usage and storage in data activities. Provenance logs are beneficial in compliance queries as they enable tracking of whether usage of data was according to the consent given at the time. They also can demonstrate retroactively how activities handled a change in consent and therefore were compliant with the permissions set forth by the user consent. Additionally, provenance logs maintain information about actions carried out and the resulting changes made by obligatory rights such as informing users of a data breach or when users request data rectification.
The PM aims to provide detective control for ensuring compliance. The CM enforces the correct behaviour of data handling systems according the consent and terms of GDPR, while the PM supports demonstrating that the correct behaviour has been undertaken for compliance reporting purposes.
The CDMM, however, does not concern with the data representation format. The
authorization of the DM works with any data model as long as the data can be
identified with an identifier [
The flows of interactions of the components are given below:
1. Consent is obtained via UIH before first-use of the service, such as when someone registers or signs in for the first time. The Consent Manager (CM) then annotates the consent using the consent ontology. The CM extracts meaningful information from the annotated consent and stores the consent validity, consent obligations and consent permissions. It also sends the provenance related information to the PM.
2. The Context Handler (CH) generates a context of arrival of a new consent (i.e. a new sign up and consent). It informs the DM and the DM can become aware of that. In case of automated data collection the DM can initiate the process and checks permission as mentioned in step 3.
3. The DM ensures adequate permissions for intended usage and processing of data exist, as specified by the consent, before any processing of data, including collection, starts.
4. When the consent is changed or updated, CH gets the context of the consent modification and informs the CM and DM. The CM identifies the change and updates the processing related information, which was created in step 1 and sends the new consent to the PM. The DM then halts the current processing and checks the new updated permissions for further processing of data.
5. A context change occurs when the intended data entity or activity changes. For example, when storage of data might shift to a different cloud storage provider, or a purpose of data collection or usage changes. An event is created based on the change and the CH is informed manually of this change. The CH then checks the consent obligation from the CM to see if it needs to interact with the user to obtain an updated consent based on the context change. If it identifies the need for a new context, it initiates interaction with the user according to the obligation provided earlier with the consent.
6. When consent is revoked, the CH informs the CM, which updates the processing information it contains to restrict access to affected data. The CH also informs the DM, which then checks the updated permission and adjusts the data collection processes accordingly. This may result in cessation of data collection based on the specific permissions and processing done by the activity. Depending on the policy of the organization it then deletes data or archives it for validity or provenance purpose.
7. The PM keeps a log of all activities involving consent and data. It records how consent was obtained based on the mechanism used by the UIH to interact with the user, the consent itself from the CM, and the activities using the consent. It also keeps a track of the data lifecycle as provisioned by the DM including activities such as storage and sharing. A record of archived consent and data is also maintained by the PM in events as described in Steps 5 & 6.
Let us consider a practical use case scenario of obtaining consent for a research project of Trinity College. A consent form is used for obtaining the consent from the Consultant Psychiatrists for interviewing them about the e-referral system for mental health service. The consent form contains information of the researcher who is collecting the data, the information about the research, procedures of the study, where and how the data will be used and a declaration which clearly states what the interviewee is agreeing to, what rights s/he possesses and the participant’s name, signature and date. The form contains the contact details of the researcher at the end. The declaration which clearly states what the interviewee is agreeing to may contain a number of options for the interviewee to choose from. In our example use case scenario the participant may choose to audio record the interview or not to audio record the interview. They are further given option to choose about using direct quote from their interview data, the options for that include i) to allow to use direct quote from their dialogue anonymously, with further review from participant ii) to allow to direct quote from their dialogue anonymously without further review from participant iii) not allowing to use direct quote in this project.
The permissions mentioned above are encoded in machine readable format and
stored as consent permission by the CM. When the researcher wants to collect
interview data s/he asks the DM if s/he can audio record the data. The DM consults the
permissions the participant provided via the interface to the CM and returns a
decision. If the decision is ‘yes’ then s/he audio records the data. While processing the
data the researcher asks the DM for the data for which there is permission for using
direct quote from the dialogue without reconfirmation. The DM consults the policies
of the participants and returns the data for which there are such permissions. The
requests and responses are logged by the PM and can be checked to verify for what
condition the data was provided to the researcher. While processing the data which
allows to use direct quote from the dialogue with reconfirmation, the DM instructs the
researcher to contact the participants via the UIH (note. this obligation to contact
participant is an obligation related to access control [
To assure GDPR compliance one requires to check consent permission before
processing data. For the automated checking of consent permission it is needed to encode
or translate the permission related information from user’s consent into machine
enforceable rules. We previously used templates for consent and converting them into
machine enforceable rules [
In order to choose the format for encoding consent we are considering two different languages for the representation of consent permissions, which are XACML and ODRL.
XACML is OASIS standards for attribute-based access control policy language. It consists of three main elements in the hierarchical structure: PolicySet, Policy and Rule. Further, rules have Targets, Conditions and Obligations. However, the real power of the language comes from its rich set of Functions. XACML is XML-centric language. ODRL, on other hand, does not have strict rules when it comes to the output. ODRL is Rights Expression Language (REL) developed to express rights, rules and conditions, including permissions, prohibitions, obligations and assertions.
When it comes to our specific use-case in annotating the consent, both languages have their strengths and weaknesses. XACML can clearly enforce the policy rule based on the consent. While it can obviously define that the certain statement has certain action associated with it, it fails to define abstract actions, such as ‘understanding’, that are not particularly associated with actions, but require user to absorb the information, with no particular consequence in failing to do so.
ODRL has Classes, Concepts and Properties to describe almost any aspect of consent. It even has specific Property consentingParty and related Concept (action) obtainConsent. But it lacks straight-forward approach of XACML and might overcomplicate certain aspects of the mapping process. When it comes to enforcement of permission, XACML has a rich mechanism for that and there are enforcement engine available for that. In that respect, and for the purpose of this paper, we use XACML as a base for our annotation of consent permission, due to its enforcing nature and clear rule definition. ODRL would be used for scenarios where XACML falls short, such as already mentioned generic concepts that presented in informal form. 5
We have implemented the preliminary version of the ontology in Protégé which can be found in https://openscience.adaptcentre.ie/ontologies/consent. Note that our ontology imports and extends PROV-O. For more information how our concepts relate to PROV-O, we refer back to Fig. 2. This version of the ontology, as discussed in Section 4, is meant to be generic and is subject to extension for specific application scenarios or application domains.
We are working on a number of real life examples of consent to validate our model. For example, consent for medical examination, consent for participating in research experiments and consent for the usage of an online service. The CM of our model is responsible for annotating the consent collected via UH. In this phase of implementation, we have manually annotated the consent examples with the elements from consent ontology to get a machine-readable version of consent, which can be invoked by the other components of CDMM automatically.
Fig. 4 shows an example of how one can annotate of a sentence in RDFa1, which
is a W3C Recommendation for embedding RDF in XHTML documents, from a
consent form that is used by a research project in Trinity College for obtaining the
consent from the Consultant Psychiatrists for interviewing them about the e-referral
system for mental health service. The sentence from consent that is used in this example
is “I agree that my data will be used for scientific purposes”. The embedded
annotations capture how one gives permission to use (Permitted Action) my data (Data) for
scientific purposes (Purpose). We used an RDFa parser 2to get RDF from the
annotated XHTML document which is presented in Fig. 5. Then we used XSPARQL [
Fig. 4. Annotation of consent with elements of ontology in RDFa. <rdf:RDF xmlns:consent="http://theme-e.adaptcentre.ie/consent/ont.rdf#" .. <consent:Permission><consent:givenFor><consent:Data> <consent:hasA> <consent:Category> <rdfs:label>interview data</rdfs:label> </consent:Category></consent:hasA><rdfs:label>data</rdfs:label</consent:Data></consent:givenFor> <consent:givenFor><consent:PermittedAction> <rdfs:label>use</rdfs:label> <consent:hasPurpose><consent:Purpose> <rdfs:label>scientific purposes</rdfs:label> </consent:Purpose></consent:hasPurpose </consent:PermittedAction> </consent:givenFor> 1 RDF in Attributes (RDFa): https://www.w3.org/TR/xhtml-rdfa-primer/ 2 https://github.com/RDFLib/pyrdfa3 The ODRL representation of the annotated example of consent of fig. 4 is presented in fig 7 (a). In this instance, the participant assigns the action ‘use’ to the researcher for the purpose of ‘scientific purpose’.
<http://consent_form> a odrl:Rule ; odrl:permission [ a odrl:Permission ; odrl:action odrl:use ; odrl: purpose “scientific purposes”; odrl:assignee <http:/researcher> ; odrl:assigner <http://participant> ; odrl:target <http://interview_data> ] ; (a) <http://consent_form> a odrl:Rule ; odrl:action [ a odrl:Action ; odrl:read odrl:reviewPolicy ; odrl:assigner <http://researcher> ; odrl:assignee <http://participant> ; odrl:target <http://resource> dc:description “I understand that I make illicit activities known” ] ; (b)
ODRL offers to express elements of consent for cases XACML can’t express. An example of consent, “I understand that I make illicit activities known”, which is taken from our consent example, does not form XACML, but makes ODRL. In the above example, fig. 7 (b) the assigner (researcher) uses the ‘read’ and ‘reviewPolicy’ ODRL concepts to require the user to read and ‘understand’ the particular policy.
This XAMCL rule – we note we excluded the whole XACML file for brevity – is
used in an authorization system which we implemented earlier [
Our consent management model will further contain the enforceable policy from
the GDPR, instead of the EU DPD which we had previously encoded in our system,
by extending our previous experiment [
Grando and Schwab [
Asghar, and Russello [
In this paper, we proposed a consent ontology leveraging existing models of
provenance, processes, permission and obligations. The proposed consent ontology forms a
semantic model of consent to make it specific and unambiguous as required by the
GDPR. We have implemented the preliminary version of the ontology in Protégé. We
further have proposed a reference architecture, called CDMM, for the management of
consent and data which embodies a bunch of design decisions beyond the ontology
and incorporates the change of context within the data processing model. The
reference architecture aims to aid the controller to assess and demonstrate their compliance
efficiently. We have illustrated a proof of concept by annotating consent examples
with the consent ontology and demonstrated a way to obtain machine readable and
enforceable format of consent using ORDL and XACML. We used the XACML
obtained from consent into a policy engine which is implemented by augmenting Sun's
implementation of XACML [
Acknowledgment. This paper supported by the ADAPT Centre for Digital Content Technology, which is funded under the SFI Research Centres Programme (Grant 13/RC/2106) and is co-funded under the European Regional Development Fund. 8