ce of the pro- posed platform by using WS-Encrypted SOAP communication. The sent request includes the SAML token issued and signed by the STS server. The request is time stamped by sending a time-stamp request and obtaining the corresponding time-stamp response (digitally signed by the TSA). The secure JAVA mobile application also receives the signed and time-stamped m-governmental document from the platform through WS-Encrypted com- munication and performs all necessary signature verifications and certificate validations (with the help of the XKMS server) actions. In the sequel, we will describe in more detail a possible m-governmental scenario. 11.2.2 Possible m-Government Community We considered a possible m-government community, consisting of [5-7]: Citizens Civil servants Administrators Depending on the scenario, it might be necessary to introduce some other roles, like delegates of either citizens or civil servants and several levels of administration here, but it is assumed that for the functional purpose of the proposed system those roles do not matter as they usually do not influence the platform processes directly. Instead, the proposed system may use the delegates themselves that are actually belonging to one of the mentioned groups. Citizens are the primary user targets of the proposed system. Using a mobile device, they access the system, initiate requests, or receive notifications pushed by the platform. Citizen delegates are handled like Civil servants, as they cannot On Secure JAVA Mobile Application access the system for someone else, due to the nature of the authentication mecha- nism. Instead they are forced to get help from a Civil servant, actually initiating the request. Civil servants are the right hand of the proposed platform. Where the platform itself and automatically is only able to check user requests for security constraints (WS-security, XML-security, time stamping, SAML, and XKMS features), Civil servants may approve or decline requests on a semantic legal level that is elusive by 