# SAM-PAY: A Location-Based Authentication Method for Mobile Environments +
## 5 Service Exploiting the SAM-PAY Method for Mobile Authentication
### Service Provider Implementation Details  
Since the Service Provider is a core element of the proposed service, we provide more details on its internal architecture and functionality. The SP system is based on a 3-tier model and is composed of the following modules: the SP Front End, the SP Application Server, and the SP Database Server. The SP Front End consists of a service portal accessed via a web interface by the users (in this use case, the customers and the gas-station managers) to access customer information and details on the functionalities of the provided service. The service portal is composed of two logical-functional areas: (i) the public area, which contains the description of the service provided and of the types of users that can register to access it, general information about the contracts that can be subscribed, contact information, such as the phone number, e-mail address, etc. ; and (ii) the private area, which can be accessed only by the users who registered for the service. Three types of users can obtain access to the private area via a login operation: the service portal administrator, the managers of the gas station providing the proposed SAM-PAY enabled-based service, and the customers who want to use the SAM-PAY-based refueling service. The SP Application Server (AS) is composed of several software components, each of which is in charge of performing a dedicated task. For example, the Service Handler is the core of the AS and implements the finite state machine of the system controlling all the transactions involving the main actors (UT, LE Payment System, Database). The Service Handler implements the logic for verifying the UT credentials and the validity of the user contract. It generates the OTC and the TOKEN, verifies the temporal validity of the TOKEN in a payment operation, verifies the user eligibility, etc. The Service Handler communicates with the database via a dedicated DB Services module, with the UT via a dedicated UT subsystem module, with the LE via a dedicated LE subsystem module, and with the Payment System via a specialized Payment subsystem module. The UT subsystem implements the interface between the Service Handler and the Web Servicesexposed by the Message Adapter of the middleware platform (TELECOM infrastructure) required for the UT-SP communication. The SP Application Server is configured with data required by the Service Handler when it exchanges data with the Message Adapter as part of the UT-SP communication, such as (i) the URL of the web service on the middleware portal, (ii) the type of messages exchanged (i.e., USSD), (iii) the authentication method (e.g., username and password), and (iv) other information such as the maximum number of retry attempts to be performed in a UT-SP communication if an operation (e.g., connect, authenticate) fails. USSD (Unstructured Supplementary Service Data), unlike the asynchronous SMS service, opens a session, which may induce other network operators or a USSD response before releasing the connection. Almost 90% of the worldwide GSM network infrastructure and nearly 100% of mobile phones available today support the transport of USSD messages via the MAP (Mobile Application Part) protocol. Mobile phones send USSD messages when the user chooses a function from a phone's menu, like call diversion to the subscriber's Voice Mailbox. Those \"simple\" applications tend to hide an aspect of USSD messages that allows the implementation of much more powerful applications on top of the USSD technology. A USSD session can remain active for some minutes. During this period (or session), the mobile phone and the HLR of the mobile network operator can exchange as many messages as they like, and this feature has been exploited in our proposed solution. In practice, the SP and the UT exchange the following USSD messages in the proposed SAM-PAY-enabled workflow:  
* UT_SP_CONNECT (IMEI, phone number): is the message sent by the UT to connect to the SP.