cate request or m-in- voice must be time stamped. In order to accomplish this, the JAVA mobile applica- tion communicates with time-stamping server via HTTP communication. In this sense, the JAVA mobile application sends a hash of the signature of the mRCertifi- cate or m-invoice to the time-stamping server and receives back a time stamp (signed hash with added time information) which is signed by the private key of the time-stamping server. Only in the mRCertificate scenarios, when the mRCertificate is ready for deliv- ery at the platform, the SWEB platform sends a SMS to the mobile user informing him that the mRCertificate with the given TaskID is ready for download. After that, the JAVA mobile application will send a request for mRCertificate download also as a signed and time-stamped request in a body of the WS-Encrypted SOAP message to the Interaction Tier Manager of the municipality. During the above-mentioned communication, in order to verify signatures and validate different X.509v3 certificates, the JAVA mobile application needs to com- municate with the XKMS server which outsources a part of the time- and resource- consuming PKI functionalities to the JAVA mobile application. Namely, the JAVA mobile application could obtain a suitable certificate from the XKMS server (by using LocateRequest XKMS function) and, more importantly, could validate cer- tificate of some party (by using ValidateRequest XKMS function). In this way, the most time-consuming PKI operations, like certificate validation, will be excluded from the mobile phone. The communication with the XKMS server is a SOAP communication without applying security features. Only, the XKMS server's response is always digitally signed by using the XML signature mechanism. 11.4.5.1 Interface Description The interfaces of the SWEB mobile client application can be divided into four groups: 1. Graphical User Interfaces-responsible for visual representation of the appli- cation, and for event handling. 2. Security interfaces-responsible for encryption, sig