## 2 Privacy Policies and Preferences in e-Government Environments  
The concept of embodying privacy policy and privacy preference documents in modern e-Government environments has been explored in [8] towards advancing and simplifying the provision of electronic services while preserving user's privacy. Through privacy policy documents, each service provider provides a formal public engagement of the information required, the purpose of the request, as well as how the information will be used and to whom it will be disclosed. Data subjects consent tothe use of their personal data by specifying, for each data item or group, fine-grained privacy preferences that define how they can and must be used. Through this procedure, the data subject is empowered to revoke the right, upon decision, that has been previously granted to a data collector to use their personal data and/or can constitute certain data items or groups be no longer validly accessible. The architecture's design is based on modern e-Government environment structures which embody a central portal; it most commonly operates as a one-stop shop, being the front-end for every service provider. Typically this portal implements the authentication and registration procedures or incorporates the federated identity management infrastructure for every service provider. Alongside to these authorities a new entity is introduced, named Privacy Controller Agent (PCA). It is responsible of storing and comparing service providers' privacy policies and user privacy preferences documents. An overview of an agents' architecture can be seen in Figure 1 below. Privacy Controller Agent consists of two main units: a management point and decision point. The management point consists of two storage repositories which are in charge of retaining the privacy policy of each service (A) and the privacy preferences of each user (B). When a SP enrolls an electronic service to the central portal (CP), apart from the other information that he is required to provide, depending on the underlying interoperability framework, he must obligatorily submit the corresponding privacy policy. Since a service provider will most commonly offer numerous different electronic services, a separate privacy policy must be submitted for each one of them. This document states explicitly which data is required for service's provision, for which purpose it is required, how it will be processed, if it will be stored, for how long it will be retained and if it will be communicated to another SP. After its submission (action i), PCA validates the policy's origins and stores it at policy repository (A). Similarly, when a user registers to the central portal, they are also required to submit their privacy preferences. Since privacy preferences regard a user's personal data, there is not a direct relation to the service they will be utilized by. Therefore, users will have to submit only one document which will apply to every electronic service. Apart from the categorization in data types (personal data and personal identifiers) and their scope of usage and processing, we propose the inclusion of characterization regarding the service provider that will process it. Thus, users will have to specify what type of data will be included in their privacy preferences, for what purpose can they be used, and by which service  
Figure 1: Privacy Controller Agent (PCA). provider. After their submission, the Privacy Controller Agent validates the preference's origins and stores them at the preferences repository (action ii). Following a successful user authentication and request of an electronic service, the central portal forwards the request to Privacy Controller Agent. The PCA then retrieves the preferences and the corresponding policy and forwards them to the decision point (action iii). At this point the comparison procedure evolves and the policy is checked against the user's preferences.