4.2 Privacy Enhancing Technologies Supporting Practice and Control
4.2.2 Consent Manager
A Consent Manager6 is a dedicated component of an ICT system that allows a
user to see which applications request access to his personal data, the purpose of the request and the circumstances surrounding the request. A given or denied consent is stored in a consent database, thus retrievable for accountability issues. In addition, the consent manager could help the user to assess the risk and benefit of a request, hence assisting the service provider in offering the user informed consent [FLM05].
A data subject may declare his consent to a service provider or withdraw a previous one at any time, thus supporting Consent, Notice and Access, Participa- tion & Accountability. The GDPR additionally demands that “it shall be as easy to withdraw consent as to give it”, Article 7(3) [Par14], thus the requirement to offer the user an easy way to manage his consent.
The consent manager is an interesting component for IoT: the user might constantly be requested to consent to services that want to collect data from his devices and offer him some value in return. The user will be able to accommodate this situation by specifying policies which support the automation the consent process. The user must be able to comprehend which services he consented to and under which circumstances.
The consent manager is therefore related to an authorization engine and a dashboard where the final decision on a conflicting request or the withdrawal of it is made by the user personally.
4.2.2.1 Related Work
Related work on the consent manager targets informed consent and a consent manager. Related work on informed consent explicates what is needed in order to inform a user adequately and in such a away that he understands the complexity of the system. The consent manager supports the user in weighting the sensitivity and the risks stemming from his consent against the foreseen benefits.
Related work on the consent manager is the delineation of a technical and/or architectural component that assists the provision of informed consent.
Informed Consent. For the sake of completeness, the reader is referred tp the consent discussion in Rerum [SWC+15] and the structure proposal of informed consent by Friedman et al. [FLM05]. The most significant insights into informed consent have been provided in the area of Health Care (HC). Researchers in the HC area have mentioned many of the shortcomings of consent that have been subject to recent privacy discussion (a.o. simple language, visualisation, risk assessment support, standard templates, see [SWC+15]). Informed consent has been identified as challenge to explain a patient7 how a complex system (his body)
works and which risks and benefits his consent (and accordingly, the treatment on his body) might have. The same applies for ICT and IoT, a complex system has to be explained to the user in order for him to understand the benefits and risks. The form and methods of explanation might be directly transferred from health care: Cassileth [CZSSM80] surveys in 1980 why informed consent misses the point of informing the user by analysing 200 patients. The methods used (oral and consent forms) were examined and new methods that improve legibility and comprehension were proposed. Appelbaum [ALM87] describes in 1987 informed consent from a clinical and legal point of view, how it affects patients in clinical practice and how the successfulness should be assessed.
More recently tools have been proposed to help the provider to assess the risk first before it is communicated to the patient. In [BLP+13] Biliomoria proposes a surgical risk calculator. The calculator is based on pre-defined clinical data of several clinical institutions. The tool was evaluated positively in Biliomoria’s survey. No such tool exists to help with the evaluation of risks for ICT / IoT based systems, but might be a practical approach if the experience of experts is integrated8.
Consent Manager. An early proposal for a consent management system for web-service environments has been published in a patent by Dunn [Dun06]. The manager is interleaved with an access control component to support the user in
7Patient is a user in IoT and other ICT systems
8The critical reader may question the need for such tools, as health care services carry
much higher risks compared to ICT-based systems. This might only be the case for treatments that directly threaten the life of the patient, but not for others. Privacy breaches might cause significant damage to the affected subjects as well, see [Sch78].
handling several consent requests. Whenever a request is not authorized, the consent management system is invoked. The validation of the request is based on the P3P language [CW07]. The user defines his preferences using the P3P preference exchange language APPEL [Con02] which are compared to the P3P policy definitions of the service and the user is presented one or more options to consent to the service or not.
Other proposals for consent management have been made recently in the area of health care. Researchers in the area of health care have mentioned many of the shortcomings of consent that have been subject to recent privacy discussion.
Dunn’s proposal [Dun06] has strong similarities with the Rerum consent manager (matching of policies and preferences, storing of consent, informing the user, interleave with access control), except for the architectural integration. Dunn considers web-services as its main use case, whereas Rerum focuses on use cases with constrained devices. The architectural integration separates both proposals, although being conceptually close.
Wang and Hongxia [WJ12] propose a consent management system based on an own informed consent model for HC. The consent manager supports weighing benefits and risks of a consent request based on expected benefit, sensitivity and relevance. Benefits maybe the treatment results of a primary physician (high) or targeted advertisement from a drug store (low). The risks are rated according to sensitivity (generally health status) and relevance, that means which data is requested and how it relates to a service (if irrelevant data is requested for a service, the risk becomes higher). Relevance is rated through statical learning methods. That means that similar requests are compared over time to learn the normal amount of data records that are needed for a special request. The manager also needs a pre-access definition by the patient and an administrator to rate how sensitive records are and how important a request may be.
The architecture of the consent manager is as follows: every request to a pa- tient’s health records is redirected to the consent manager. Based on the statistical learning engine, requests are rated and a decision (accept, deny) is suggested to the patient. On acceptance requests are accepted and responded to accordingly. This architecture resembles that of Dunn [Dun06] and Rerum [SWC+15]: the
redirection is part of all proposals, although an enforcement point and XACML are not directly mentioned in [WJ12]. A benefit-risk calculation and formalization is missing in [Dun06,SWC+15] but found in [WJ12]. The proposals in [Dun06,WJ12] do not consider a real-time data consumption stoppage by revoking the consent, which is formulated in [SWC+15]. Only [WJ12] was implemented and evaluated over an increasing scale of patients and requests.
In summary, consent management is a maturing technology. Advances can be found in health care scenarios, especially in the presentation of informed consent and benefit-risk evaluation. Architectural extensions for IoT scenarios are marginal, but the overall architecture has been similar through all proposals and can be applied to IoT as well. How well existing consent managers can be carried over to IoT, particularly those of health care, remains an open question.
4.2.2.2 Integration in the Rerum Domain Model
The architectural location of the consent manager is discussed here and subse- quently put into relation with the consent manager via the sequence diagram shown in Figure 4.5.
In the Rerum Middleware the service manager is located conceptually at the Security Center, he interacts with the Rerum Devices and the data processing parties above the Middleware, see Section 2.5.4. The consent manager is essentially a part of the Security Center as it interleaves with other security services such as the authorization framework. For simplicity, it is assumed that the consent manager can create authorization policies and access information (such as tokens9),
and that the VRDs can evaluate this kind of information. Figure 4.5 depicts the sequence of consent gathering based on a formerly unknown and unauthenticated request.
9Tokens, tickets and similar artefacts are structured access control information of authentica-
Figure 4.5: Sequence of the acquisition of user consent
Assuming that a new application requests access to personal data from a VRD, the functional interplay between the components is as follows:
1. A new application requests access to a set of private data residing in the Virtual Rerum Device. The VRD checks for access policies. At this point, there are none, as the service has never been authorized before.
2. The VRD redirects the request to the Consent Manager, as the user has to decide on granting access. Possibly, a user-defined policy could be used to give consent to certain applications. For instance, the policy could state that access is granted only to certain statistics of the user’s data or only to requesters with reputation ranking of high or above and with a certificate from a certain given trusted group.
the specific purpose for requesting the data, how the data will be processed and which data it wants to gather specifically.
4. The Consent Manager checks the request for policies or existing consent. The application is notified that none was found and that the user has to approve the request.
5. Upon checking the request, the Consent Manager includes the purpose information in a notification message and sends it to the user. The Consent Manager will wait for the approval of the user.
6. The user gives his consent. He accepts this service to access specific data for a certain purpose. The consent is recorded. (Please notice that besides this consent, an access control layer is also on effect. It is reasonable that in some cases, the accessing service must present particular credentials of the user on behalf of which he is accessing the data in order to grant some information to that user. Those credentials should be evaluated at the access control policy enforcement point).
7. After successfully gaining consent from the user, the Consent Manager triggers the creation of access policies for this application, including the data it is allowed to access, the way the data should be processed and the purpose.
8. The Consent Manager then redirects the application to the VRD and 9. Requests access with the attached access information.
10. The VRD checks the given access information. 11. On success, the VRD allows access.
Figure 4.6 shows a snapshot of Rerum’s consent manager in the context of the indoor use case in Tarragona.
Figure 4.6: Rerum Consent Manager: Example for consent request in the UC-I2 trial
In Rerum, the consent manager interleaves with the access control layer to trigger the creation of policies, to authenticate the user, retrieve his consent, to validate if a request shall be automatically consented by means of user policies, etc. Differences and similarities with the access control layer are further addressed in [SWC+15].