# Privacy-Aware Access Protocols for MEC Applications in 5G +
## 3 Statement of the Problem
### Privacy Requirements
#### 3.3.1 Justification of Requirements  
The privacy requirements above are defined assuming that the parties are independent, i.e., they do not share information with other parties unless it is necessary for providing services. One example of where the parties are independent is when they are parts of different companies. In our system model, these parties cooperate with each other, but they should avoid sharing confidential information related to their business and customers. When two parties are dependent, they may share information with each other, even when it is not necessary to provide services to the user. In this case, some privacy requirements do not apply. Dependent cases are discussed further in Section 3.3.2. We cannot typically predict how the information will be used in the future. That is why some of our requirements, particularly those concerning unlinkability, may appear to be stringent. Requirements about MNO (R1-R5)  
[PERSON] is one of the subscribers of MNO. While setting up the subscription, [PERSON] may have shared her personal information with MNO. That information that [PERSON] provided, together with the shared identity IMSI, and shared keys, should be enough for MNO to provide services to [PERSON] in our scenario. MNO does not need to know which MEC application [PERSON] is using, the identifiers she shares with the MEC application, or the content she receives from the MEC application. If MNO can detect which identifiers [PERSON] has or which MEC application [PERSON] uses, then MNO can also figure out how often she uses the application. This information can reveal the interests of [PERSON] and her daily habits. As a result, MNO may provide, for example, unwanted and targeted advertisements or special offers to her. Requirements about MEC (R6-R10)  
MEC delivers messages of [PERSON] from MNO to the MEC application, and vice versa. MEC only needs to know the destination of the messages, i.e., to which MEC application should the messages be transferred. The authorization of the user is performed by MNO and the MEC application. In our scenario, services of MEC do not depend on whether the user is authorized or not. Therefore, MEC should not learn why [PERSON] uses the MEC application or know details about her, such as her real name and her identifiers for MNO and the MEC application. Requirements about APPIFY (R11-R14)  
[PERSON] wants to use the MEC application. Before she starts using the application, it might require authenticating or requesting some information from her. For these purposes, the MEC application should either ask for information directly from [PERSON] or use a third-party authentication service, which both [PERSON] and the MEC application agree with. In any case, the MEC application should not gather any information from any party other than [PERSON]. However, [PERSON] may give the MEC application some details about her, such as her real name or a fake name, home address, and phone number, to improve the user experience with the MEC application. In addition, APPIFY may learn some information due to the nature of the scenario, even though [PERSON] does not provide it herself. One example is the approximate location of [PERSON] because APPIFY finds out that she should be somewhere close to where the MEC is located. For the quality of the service, the MEC application might want to know what type of device the user has. However, the MEC application should not know which individual device the user has when connecting to it. Furthermore, the MEC application should not relate two messages sent from the same individual device or use the same IMSI for connection to MNO. For example, assume that [PERSON] is another user of the MEC application APPIFY and has the identifier Bob57, while the identifier of [PERSON] is Alice13. [PERSON] may use APPIFY in his IoT device, and this device is connected to the internet through the mobile device of [PERSON].