# SAM-PAY: A Location-Based Authentication Method for Mobile Environments +
## 5 Service Exploiting the SAM-PAY Method for Mobile Authentication
### Service Provider Implementation Details
The Service Handler accepts the incoming connection when the UT (identified by its IMEI--International Mobile Equipment Identity) and the associated phone number are successfully found with success in the SP Database. When the connection has been established with success, the Service Handler returns to the UT a session ID, which will be used in the subsequent steps. If the connection establishment fails, the SP returns to the UT the failure reason, such as \"user contract expired/not active\" or \"phone number not registered\". * UT_SP_AUTHENTICATE (session ID, username, password): is the message used by the UT to authenticate it to the SP using the username and the password set by the user in the registration phase. In case of authentication failure, an error message is returned to the UT, such as \"UT not connected\", \"user not active\", or \"Uname/PW not valid\". * UT_SP_GETTOKEN (session ID): is the message used to retrieve the 32-byte-long TOKEN from the SP. If the operation is completed with success, the Service Handler returns to the UT the token together with the token lifetime (expressed in seconds). Otherwise, an error message is returned, such as \"UT not connected\", \"UT not authenticated\", \"connection with LE failed\", or \"Token generation failed\". * UT_SP_PAYINFO (IMEI, phone number, username, password): is the message sent by the SP to inform the user about the status of the last \"n\" payment operations. Each message is at most 80 bytes long and contains several (data, length, value) tuples, like the numeric code of the command--such as request session ID or request token--recognized by the SP, the current date and time, and the message checksum. Similar messages are also exchanged between the LE and the LE subsystem module of the SP via a dedicated adapter provided by the middleware platform. Besides the SP_LE_CONNECT, SP_LE_AUTHENTICATE, and the SP_LE_DISCONNECT messages, we also encounter the SP_LE_GETPOSITION message, which is sent by the SP to the LE to obtain the certified position of a UT. The Payment subsystem is divided into two submodules: the SP-POS module is in charge of the management of the transactions between the POS and the SP, whereas the SP-ABS module manages the transactions between the SP and the e-wallet ABS Card system. In both cases, a TCP/IP connection is established between the communicating parties. To interact with the POS device, the SP's Payment subsystem communicates internally with a dedicated HGEPOS Adapter, which is a software infrastructure implementing the interface between the SP-POS module of the Payment subsystem and the POS device. The messages exchanged between SP and the SP-POS module are: POS_SP_OPEN (POS SIA Code, operation number), which is the message sent by POS to the SP for the opening of the accounting transaction; POS_SP_PREAUTO (POS SIA Code, Operation number, OTC, max amount), which is the message sent by POS to the SP for the execution of the preauthorization operation; POS_SP_NOTIFY (POS SIA Code, Operation number, OTC, effective amount), which is the message sent by POS to the SP for the execution of accounting notification; and POS_SP_CLOSE (POS SIA Code, Operation number), which is the message sent by POS to the SP to indicate that the accounting transaction has been closed. The transactions among the various actors are grouped in operational flows, each of which is composed of several phases. Each phase can be associated with a status (in progress, completed with success, or failed). The Service Handler keeps track of all the phases executed inside an operational flow, and all the relevant log trails are stored in the SP Database. The SP Database Server is based on an Oracle database and contains the objects (Tables, Views, Procedures, etc.) required for the storage and management of the information of the Service Provider. The communication between the SP Application Server and the database server is implemented via the Oracle JDBC driver connection.