GUF, KAU, ATOS, AIT, TUG, LISPA
This deliverable performs a privacy analysis on the CREDENTIAL Wallet architecture, which is presented in CREDENTIAL Deliverable D5.1 . We try to organise the work based on a sound methodology, which we considered to fulfil our needs. In our case, we considered LINDDUN , which is a methodology that helps consider privacy during the development lifecycle. However, we also acknowledge that there is a lack of a mature methodology, which we could fully rely on, therefore we made sure to adapt it to our needs rather than blindly follow it step by step. Therefore, we split the process of performing the privacy analysis in five main steps1 corresponding to the steps performed in LINDDUN. Each step defines an own chapter in the deliverable.
The deliverable starts by introducing the project objectives and explain the organisational structure of the document. Next, we describe the methodology (LINDDUN), how we applied it, where we deviated from it, and why we did so. Following, we provide a system description of the CREDENTIAL Wallet architecture in the form of a DFD (Data Flow Diagram). This is then used as a basis for the next steps in the privacy analysis, most importantly for identifying the privacy threats in the system.
Next, following LINDDUN, we map privacy threats to the respective DFD elements in the system. Here, we end up with a large number of threats, which become unmanageable if we choose to follow LINDDUN, because of the complexity of the system. Therefore, we make a prioritization of threats based on interviews with experts into three main categories: high, medium, and small risk threats. We then focus on the first two categories, for which we then separately identify corresponding risk mitigation strategies. Here we also deviate partly from LINDDUN and rely on the mitigation strategies from ISO/IEC 27005  instead, since LINDDUN does not provide a strategy that for instance accepts a certain risk, which we acknowledged is normally needed. We explain this in more detail in the corresponding chapter (Chapter 2 - Methodology).
Finally, for the high and medium-risk threats, we propose concrete mitigation mechanisms, which is aimed to serve as a feedback to the ongoing work in the project in the design of the CREDENTIAL Wallet architecture. We categorize the mitigation mechanisms in three groups: first, the mitigation mechanisms that require integration of specific technological tools in the Wallet architecture; second, mitigation mechanisms that require adherence to particular development “guidelines and principles”; and third, mechanisms that rely on organizational measures, such as proper privacy policies or third party contracts.
Finally, based on the experience and the expertise in the project, and considering the requirements from Deliverable D4.1  on the technologies, we make a number of high level recommendations for CREDENTIAL, but also for other projects that consider privacy. These recommendations are mostly targeting system architects and software developers that aim to consider privacy in their projects considering different requirements and limitations. However, we also give important recommendations, which target regulatory bodies, such as national data protection agencies, in monitoring companies and organisations in privacy-related matters.
The full version of this deliverable can be downloaded here.