An Alternative Architecture for SIM-Based Mobile NFC Services

Abstract

Near Field Communication (NFC) enables mobile handsets to perform bidirectional wireless proximity communications with other electronic devices. From an end user point of view, Mobile NFC Services (M-NFC-Ss) are expected to replace plastic cards (e.g. for payments) by bringing improved convenience and functionality. SIM cards have been used to secure the data and applications that implement M-NFC-Ss. A total of 300 commercial and pilot initiatives have been reported in 2015. However, no commercial solution has succeeded in reaching out the mass market with few exceptions in special institutional settings (e.g. Japan). Some of the explanatory factors lie in the technical architecture used. For example, GSMA recognised the need to cut as much as 75% out of its complexity. We present an alternative architecture to deploy SIM-based M-NFC-Ss, which is derived from four individual proposals: eliminate the Wallet, centralise the TSM functionality, use OTI instead of OTA, and eliminate certain technical integrations.

1 Introduction

1.1 Background

Near Field Communication (NFC) is a standardised technology that enables bidirectional wireless proximity (i.e. a few centimetres) communication between electronic devices. The introduction of NFC interfaces in mobile handsets enabled the emergence of Mobile NFC Services (M-NFC-Ss). From an end user point of view, these are expected to replace plastic cards (for payment, ticketing, transport, etc.) by bringing improved convenience and functionality. An example of improved convenience is performing payments by tapping a mobile handset in a Point Of Sales (POS) terminal instead of swiping a plastic card. An example of improved functionality is displaying real-time information about M-NFC-Ss through Mobile Applications (MAs), which is something that is not possible to do in plastic cards as these do not possess display capabilities.

A central component for M-NFC-Ss is the Secure Element (SE), “a secure microprocessor (a smart card chip) that includes a cryptographic processor to facilitate transaction authentication and security, and provide secure memory for storing payment applications (e.g., American Express, Discover, MasterCard, Visa and other payment applications). SEs can also support other types of secure transactions, such as transit payment and ticketing, building access, or secure identification” [90]. Traditionally, the role of the SE has been served by the Universal Integrated Circuit Card (UICC) [29], which is popularly referred to as the Subscriber Identity Module (SIM) card.

The use of SIMs as SEs for M-NFC-Ss made Mobile Network Operators (MNOs) key actors in the business ecosystems required to deploy M-NFC-Ss. A Service Provider (SP) (e.g. a bank or a transport company) wishing to securely offer M-NFC-Ss has to be granted access by MNOs to space in SIMs. In addition to MNOs and SPs, two business roles are particularly important to deploy M-NFC-Ss [18, 26]: the Trusted Service Manager (TSM) and the Wallet Provider. Broadly speaking, the TSM bridges infrastructures of SPs and MNOs to allow end users’ service credentials to be sent from SPs to mobile handsets and SIMs. Wallets are MAs that provide Graphical User Interfaces (GUIs) for M-NFC-Ss installed in SIMs.

1.2 Problem

In 2015, the Groupe Speciale Mobile Association (GSMA) reported a total of 300 commercial and pilot initiatives [29]. However, despite the large number of attempts, M-NFC-S deployments are so complex that no commercial solution has succeeded in reaching out the mass market with the exception of a few cases in special institutional settings (e.g. in Japan) [7]. The reality is further paled by the failure of flagship initiatives for the industry [e.g. Isis/Softcard in the United States (US)] and the emergence of alternative non-SIM based solutions [e.g. Apple Pay and Host Card Emulation (HCE)].

The typical technical architecture currently used to deploy SIM-based M-NFC-Ss has been particularly subject to criticisms. For example, in terms of functionality [71], complexity [4], costs [8], and scalability [48]. Although urgent for the telecom industry, scientific research on SIM-based M-NFC-S deployments, particularly on technical factors hindering their success, is still limited [7, 35, 39, 83].

1.3 Contribution

In Sect. 3, we describe the typical architecture currently used in SIM-based M-NFC-S deployments. This architecture serves as our theoretical background and, as such, it helps future research to criticise the fundaments of our work, to replicate our results, to reach alternative or complementary proposals, and to accumulate knowledge over time.

In previous work [39], we have presented a framework that identifies twenty-six factors that hinder the success of SIM-based M-NFC-S deployments. Four of these factors, which are described in Sect. 4, directly depend on the technical architecture. We use these four factors as our drivers to change the current architecture.

Section 5 describes the main contributions of this article: (1) we advance and discuss four individual proposals to address the four factors identified as hindering the success of SIM-based M-NFC-S deployments; and (2) by applying these four proposals, we derive an alternative architecture for SIM-based M-NFC-S deployments.

Practitioners can use our alternative architecture to its full extent or as a reference for discussing implementation options. Section 6 describes the main limitations and strengths of this research, and proposes some directions for future work. Conclusions are provided in Sect. 7.

2 Related Work

From a review on mobile payments’ literature (not specifically SIM and NFC-based), Dahlberg et al. [7] identified 44 technology oriented articles published between 2007 and 2014, and observed that approximately 75% of these articles focused entirely on security. Furthermore, Dahlberg et al. [7] observed few propositions for new technologies, and only rare comparisons of alternative technological solutions. In light of the broad observations from [7], assuming that literature on mobile payments is representative of the literature related with our work, we distinguish ourselves by not focusing on security, by proposing an alternative technological approach, and by comparing it with the current standard approach. More specifically, GlobalPlatform [24] is the standard industry specification to guide M-NFC-S deployments, and therefore we use it thoroughly to describe the typical architecture to deploy SIM-based M-NFC-Ss. In addition to [24], four references are particularly relevant: [2, 35, 45, 83].

Lee et al. [35] proposed a framework to help practitioners choosing a suitable architecture for deploying M-NFC-Ss. We distinguish ourselves from [35] in three ways. First, we focus on the SIM-based approach, while [35] considered also other possibilities (e.g. embedded SEs). Second, we concentrate on detailing and justifying a specific architecture, while [35] concentrated on describing twelve factors that should be taken into account to choose between five high level architectural options (with one mapping to our proposal). Third, only one of the twelve factors pointed by Lee et al. [35] is considered in our work (i.e. Over-The-Air (OTA)), and none of the four factors that we consider relevant was specifically taken into account by Lee et al. [35] (see Sect. 4). We consider six factors from [35] as irrelevant to architectural design of the SIM-based approach (i.e. the factors related with the location of the SE and with the distribution of NFC devices). We consider the three service mode factors from [35] to have little relevance in general (i.e. card emulation mode, Peer-To-Peer (P2P) mode, and reader mode). Empirical results presented by Lee et al. [35] support the little relevance of the service modes. Finally, we consider two factors from [35] as not worthwhile of discussion in practical implementations (i.e. to have multiple M-NFC-Ss in a mobile handset, and to have a GUI for a M-NFC-S).

Ok et al. [83] defined requirements for a NFC ecosystem and, based on these requirements, designed a TSM centric architecture that adopted a role-based service level communication structure. In essence, Ok et al. [83] defined a set of roles (i.e. TSM, card holder/end user, Controlling Authority (CA), OTA provider, and card issuer/SP) and their responsibilities. For example, for the TSM, Ok et al. [83] argued that it needs to manage trust in the ecosystem, to manage the lifecycle of M-NFC-Ss, to provide the necessary technological support, to provide an application pool, and to manage agreements. Given that it is aligned with the general GlobalPlatform’s proposition for NFC ecosystems [18], and that it is presented on a higher abstraction level than [24], the work of [83] does not add significant value to our work relatively to [24].

Munch-Ellingsen et al. [45] proposed an architecture for M-NFC-Ss based on a TSM proxy running on the Operating System (OS) of a mobile handset. The proposal to use a TSM proxy is discussed in detail in Sect. 5, particularly how it relates to our work.

Akram et al. [2] presented an architecture for SIM-based M-NFC-Ss that allows end users to deploy their own M-NFC-Ss. Although this could be an interesting possibility in the far future, it does not really address factors that are hindering in practice the success of M-NFC-S initiatives, which is a core motivation of our alternative architecture.

3 Current Architecture

Figure 1 describes the typical architecture to deploy SIM-based M-NFC-Ss. GlobalPlatform [24] described five main actors: the SP, the MNO, the TSM, the CA, and the SE Provider. In the context of this article, the SE Provider is the MNO, and therefore it is merged with the MNO and not identified explicitly. The CA is not a relevant actor in light of the challenges observed in the deployment of M-NFC-Ss (see Sect. 4) and the alternative architecture proposed by this article (see Sect. 5). For the opposite reasons, contrary to [24], we introduce the actor Wallet Provider, the components Wallet and Widget, and the Business-To-Business (B2B) processes.

Fig. 1

Typical architecture for SIM-based M-NFC-Ss

The main purpose of the architecture in Fig. 1 is to manage the lifecycle of M-NFC-Ss, particularly the following operations: deployment, suspension/lock, resumption/unlock, update, upgrade and deletion/termination. For the purpose of this article, it is sufficient to detail only the deployment operation, because it is the most important operation, the most complex, and is representative for all the challenges presented by the other five operations. Deployment is triggered by the SP following a dedicated enrolment process involving the end user. After deployment, a M-NFC-S is installed in the mobile handset of the end user, and suspension/lock, resumption/unlock, update, upgrade and deletion/termination operations may follow directly or as reactions to events or situations that may have impact on the status of M-NFC-Ss (e.g. mobile handset change, mobile handset lost/stolen/recovered, SIM changed, etc.).

A M-NFC-S is typically composed by a combination of a Widget (not standardised term) and an Applet [21] (equivalent to the term SE Application used in [24]). Generally speaking, the Widget is responsible for the functionality and GUI required for the interaction between the end user and the M-NFC-S, and the Applet is responsible for securing the M-NFC-S and for the NFC based interaction between the M-NFC-S and the POS terminal found, for example, in a merchant’s location or at a transport entry point.

The Widget complies to a general execution framework provided by the Wallet. In its most complex implementation, this execution framework is a virtual machine running on top of a mobile handset’s OS that provides a runtime environment capable of executing a plurality of Widgets and configured to enable the Widgets to be operable on any of a plurality of OSs [9, 88]. Within this framework, each Widget has the ability to show a GUI containing forms and graphics, the ability to contain business logic and process data in order to make decisions, the ability to store data, and the ability to communicate with backend servers. In its most simple implementation, the execution framework can be a simple placeholder for an image containing, for example, a brand’s logo (e.g. see Apple’s Passbook/Wallet).

The Applet complies to an execution framework provided by the SIM’s OS. The dominant one is Java Card Open Platform (JCOP) which is compliant with both the Java Card specifications [91] and the GlobalPlatform Card specifications [21]. To guarantee Applet portability, this execution environment is comprised of a number of components that ensure hardware and vendor neutral interfaces to MAs and backend servers. Moreover, it is comprised of special key and security management applications called Security Domains (SDs), which exist to ensure complete separation of data between Applets in different SDs and MAs or backend servers [21]. An example of an Applet is the Visa Mobile Payment Application (VMPA) designed to implement the Europay, MasterCard, and Visa (EMV) logic to support a payment transaction from Visa.

Applets and Widgets are bound to each other by a security mechanism called Secure Element Access Control (SEAC) [20]. This mechanism is used in addition to existing protection mechanisms [e.g. permissions in the OS to limit access to sensitive Application Programming Interfaces (APIs)]. SEAC prevents unauthorised selection of SDs or Applets in the SIM motivated by denial of service attacks (e.g. Personal Identification Number (PIN) blocking, selection of non multi-selectable Applets, etc.). SEAC is transparent to the Widgets and Applets, and is enforced by the OS in the mobile handset, thus it is not hamper proof. The rules to configure the SEAC are stored in the SIM, and therefore are primarily managed by the MNO’s backend server. However, the responsibility for changing these rules can be delegated to other actors.

Deployment of a M-NFC-S requires the following actions [24]: (1) an eligibility check process to evaluate if the conditions exist to deploy the service; (2) creation of a SD to secure the service in the SIM; (3) personalisation of the SD with keys that are only known to the party responsible to secure the service; (4) installation of an Applet in the SD; (5) personalisation of the Applet; (6) activation of the Applet; (7) installation of a Widget in the Wallet; and (8) binding of the Widget to the Applet. Before these actions are taken, the Wallet must be installed by the end user.

The role of the Wallet is not clearly defined as there is no single organisation yet with the authority to standardise it. However, in general, the Wallet is expected to [26, 28, 42, 90]: (1) act as a digital container and access point for payment cards, tickets, loyalty cards, and other items that might be found in a conventional wallet; (2) be open and ubiquitous, accepted at most merchant locations, and across a multiplicity of different terminals; (3) provide a consistent experience for the end user regarding design, branding, and functionality, particularly regardless of the mobile handset it is running on; and (4) take a central role in the communication with the SIM and in the management of certain shared services (e.g. access to the NFC interface). The Wallets are typically discovered and installed by end users through OS specific application discovery stores such as Google Play for Android (earlier was called Android Market) and App Store for iOS. Wallets serve themselves as discovery points for M-NFC-Ss from multiple SPs, and thus enable the deployment of these services. Examples of Wallet Providers are Proxama, Helixion, Toro, Corfire, etc.

GlobalPlatform [24] defined nine Functional Groups (FGs) to execute the eight actions described previously required to deploy a M-NFC-S: Global Eligibility Information (GEI), Secure Element Information (SEI), Device Information (DI), Mobile Subscription Information (MSI), Global Service Management (GSM), Card Content Management (CCM), Personalisation Script Management (PSM), Script Sending (SS), and Device Application Management (DAM). These FGs guarantee a consistent functional behaviour using criteria such as the type of action to be executed, the type of privileges required to execute the action, and the level of technical abstraction of the action. Each FG also includes functions to perform other operations than deployment (i.e. suspension/lock, resumption/unlock, update, upgrade and deletion/termination).

GEI, SEI, DI, and MSI allow to evaluate if a specific mobile environment is eligible to receive a specific M-NFC-S. Criteria that may be used to perform this eligibility check includes business and technical factors. SEI provides information about the SIM (e.g. JCOP compliant or not), DI provides information about the mobile handset (e.g. NFC capable or not), and MSI provides information about the mobile subscription (e.g. end user is customer or not of the MNO). GEI provides an abstraction of SEI, DI and MSI, and is implemented from the SP’s backend server (as a function requester) to the TSM’s backend server (as a function provider). SEI and MSI are implemented from the TSM to the MNO. DI is provided to the TSM by the MNO’s or by the Wallet Provider’s backend servers. Following this distribution of responsibilities, the TSM, the MNO, and possibly the Wallet Provider, contribute to the eligibility criteria. However, it is the SP that takes the final decision regarding the existence or not of conditions to deploy a M-NFC-S. This article defines Secure Element Information Server (SEIS) as the component in the MNO that serves SEI requests. The Device and Mobile Subscription Registrar (DMSR) serves MSI and DI requests [24].

CCM loads, installs, and removes SDs and Applets from the SIM [21]. Furthermore, it binds Applets to Widgets. JCOP compliant SIMs take into account that MNOs may not want to perform CCM, particularly over content which does not belong to them (e.g. a VMPA). To provide flexibility on whom can execute CCM, three CCM modes exist [24]: (1) Simple Mode in which the TSM requests the MNO to perform a CCM function on its behalf; (2) Delegated Mode in which the TSM is able to perform a CCM function, but it requires a specific pre-authorisation from the MNO; and (3) Dual Mode in which the TSM is able to perform a CCM function without any specific pre-authorisation from the MNO. As CCM may be performed by the TSM, the MNO or both, in Fig. 1, we place the responsibility for CCM between the TSM and the MNO. We define Card Content Management Server (CCMS) as the component in the MNO that responds to CCM requests from the TSM.

PSM is responsible for the generation and securitisation of the Applet personalisation script. End user data needs to be prepared and formatted to serve as an input for the PSM functionalities (see Data Preparation role in [10]). After PSM is executed, the Applet contains data that is specific to an end user. In order to perform PSM, an actor needs to hold the SD keys that secure the communication between a backend server and the Applet in the SD. GlobalPlatform [24] defined two possible options regarding whom should hold the responsibility for PSM: (1) in Service Deployment Mode #1, the SP is responsible for PSM; and (2) in Service Deployment Modes #2 and #3, the TSM is responsible for PSM. Service Deployment Mode #1 guarantees that neither the TSM or the MNO can see the personalisation data. Modes #2 and #3 guarantee that the MNO cannot see the personalisation data. Modes #2 and #3 are further differentiated on how the responsibilities for GSM are divided. As a consequence of the possible division of responsibilities, in Fig. 1, we place PSM between the SP and the TSM.

In the context of the deployment operation, SS is responsible for sending CCM and PSM execution scripts to the SD in the SIM. GlobalPlatform [24] essentially equated SS to OTA. OTA is a mechanism that allows the exchange of secured packets between a backend server and an entity in the SIM by leveraging on the mobile network provided by the MNO [11]. Examples of OTA protocols are Short Message Service (SMS), Bearer Independent Protocol (BIP), and Remote Application Management (RAM) over Hypertext Transfer Protocol (HTTP) [24].

An example of an OTA implementation is presented in Fig. 2. An OTA channel is requested by the TSM using the [24]’s BeginConversation Request (a SS message) to the Over-The-Air Server (OTAS) (step 1 in Fig. 2). The OTAS is then responsible for the establishment of the OTA channel. The BeginConversation Request provides the Integrated Circuit Card IDentifier (ICCID) (a unique identifier for the SIM) and/or the Mobile Station Integrated Services Digital Network (MSISDN), i.e. the unique mobile handset number that allows to identify the mobile subscription throughout the mobile network that can be used to reach the SIM. If only the ICCID is provided (e.g. if the TSM is not allowed to hold the MSISDN for end user privacy reasons), then the OTAS needs to retrieve the MSISDN from the DMSR (step 2). The OTAS then requests the Short Message Service Centre (SMSC), an existing component in the MNO responsible for sending SMSs, to deliver an SMS to the mobile handset containing the parameters required to request and establish the OTA channel (step 3) [12]. The SMS is then delivered to the mobile handset (step 4), and the information to request the SIM to pull an OTA channel is decapsulated from the SMS and delivered to the SIM (step 5, which uses RAM over HTTP as an example). In the SIM, a RAM over HTTP Client collects the information and requests the opening of a RAM over HTTP channel to the OTAS over a 3rd Generation Partnership Project (3GPP) bearer (i.e. a bearer commonly used in mobile network communications for voice and data traffic) [19]. When the OTA channel is established, the OTAS acknowledges it to the TSM using the BeginConversation Response (step 7). The TSM can then make use of two additional SS functions, SendScript and EndConversation, respectively to send scripts to the SD and close the OTA channel.

Fig. 2

An example of an OTA implementation

As Fig. 2 illustrates, OTA leverages on several existing functionalities in the MNO (e.g. DMSR, SMSC, and 3GPP bearers). Moreover, it has potential applications that are broader than M-NFC-Ss. Therefore, typically, the MNO holds the OTAS. However, GlobalPlatform [24] also considers the possibility that the OTAS is in the TSM. For example, in a scenario where the TSM provider is already providing SMSC, DMSR or SIM functionalities to the MNO as hosted services, it may be more efficient to also outsource the OTAS to the TSM provider. As a consequence of the possible division of OTA’s responsibilities proposed by GlobalPlatform [24], in Fig. 1, we place SS between the TSM and the MNO.

As it is out of its scope of standardisation, GlobalPlatform [24] has not discriminated Widget from Wallet and has not acknowledged the Wallet/Widget architecture presented in Fig. 1. Both Wallet and Widget fit in [24]’s concept of Device Application (DA). DAM allows to request DAs to be loaded into the mobile handset and managed so that they can serve as the end user’s frontend to the M-NFC-S. We define Device Application Management Server (DAMS) as the component that provides DAM functionalities. DAM is requested by the TSM to the MNO or to the Wallet Provider (DAMS is omitted in Fig. 1 for the Wallet Provider).

Using Over-The-Internet (OTI), the Wallet Provider and the SP manage, respectively, the Wallet and the Widget using proprietary interfaces. As none of the terms is standardised, both are used in specialised and generic contexts, and both can make use of similar mechanisms, OTI and OTA are often misunderstood, confused with each other, or simply used as synonyms. To establish their difference, this articles defines OTI as a communication mechanism available to all MAs that may rely on MNO specific technologies (e.g. 3GPP bearer supported data traffic) but may also use MNO independent channels (e.g. through Wifi cellular networks). Contrary to OTI, OTA is not available to all MAs, but only to the ones authorised by the MNO. Moreover, OTA necessarily relies on MNO specific technologies (see specific examples in Fig. 2).

GSM handles, on a higher abstraction level, the scheduling of CCM and DAM. GlobalPlatform [24] defines two possible options regarding whom holds the responsibility for GSM: (1) in Service Deployment Modes #1 and #2, the TSM is responsible for GSM; and (2) in Service Deployment Mode #3, the SP is responsible for GSM. These three modes indicate that the responsibility for GSM is potentially divided between the SP and the TSM, as Fig. 1 illustrates.

In practice, the TSM role is split in two components: the SP-TSM and the MNO-TSM [27]. Generally speaking, the former component takes the TSM functionalities more closely associated with the SP side, and the later component takes the TSM functionalities more closely associated with the MNO side. GlobalPlatform [24] has not recognised the concepts of SP-TSM and MNO-TSM. However, in an attempt to speed up and streamline M-NFC-S deployments, GlobalPlatform published an End-to-End Simplified Service Management Framework in which these concepts have been introduced [22]. This framework was naturally built on the flexibility offered by GlobalPlatform [24] but made it more easy to operationalise by: (1) defining specific configurations to single vertical segments (e.g. transports or payments); (2) building upon the typical design of commercially available solutions; and (3) delimiting the number of potential functional options available (e.g. use only the Simple and Delegated CCM modes). As a consequence of this work, the concepts SP-TSM and MNO-TSM became, to a certain extent, recognised and standardised within GlobalPlatform. However, as [22] resulted from a simplification of the full potential of TSM functionalities described in [24], we consider the interface and the consequent division of responsibilities between the SP-TSM and the MNO-TSM as only partially standardised.

GlobalPlatform [22] presented a few different scenarios which imply differences to whom holds the responsibility of the nice FGs presented previously. In none of the scenarios, the MNO-TSM holds responsibility for GSM, GEI, and PSM. Consequently, we exclude these three FGs from the interface between the SP-TSM and the MNO-TSM. Regarding the other six functional groups, GlobalPlatform [22] considered that both the SP-TSM and the MNO-TSM may be involved in their execution. Therefore, we place potential responsibilities for SEI, DI, MSI, DAM, SS, and CCM also in the interface between the SP-TSM and the MNO-TSM.

Most often, providers of SP-TSM and MNO-TSM services to a M-NFC-S initiative are different. For example, in France, the Cityzi project involved Gemalto and Oberthur [46]. In Spain, La Caixa is connecting to Vodafone, Orange, and Telefonica using at least Morpho and G&D [79]. In Norway, both Gemalto [6] and G&D [16] offered TSM services to Valyou. In Switzerland, Tapit was served by two different TSM providers [31]. Consequently, we assume that typical deployments have different providers for SP-TSM and MNO-TSM services. Depending on their implementation, TSMs may be shared by SPs or MNOs.

B2B processes: (1) are not specific to M-NFC-Ss but apply also to existing services offered by SPs and MNOs; (2) need to be customised to M-NFC-Ss, thus depend on specific deployment options taken; and (3) are critical to mass successful deployment of M-NFC-Ss. Examples are incident management, customer care, contract establishment, billing, reporting, provisioning of static data, reconciliation of data, etc. We take B2B processes into account because without these processes in place, even if the basic TSM/Wallet infrastructure is functional, the M-NFC-Ss cannot scale in terms of end users, SPs and MNOs. GlobalPlatform [24] deliberately excluded B2B processes from its specification activities. Consequently, as Fig. 1 illustrates, M-NFC-S initiatives must rely on the B2B processes of each actor, which are not technically integrated and therefore require always manual intervention.

4 Drivers for Change

In previous work, we have identified several factors that hinder the success of M-NFC-S initiatives [39]. For example, lack of governance and leadership, lack of trust, conflicts and rivalry, strategies by MNOs and SPs, lack of NFC standardisation and adoption of NFC mobile handsets, insufficient seeding of NFC-capable SIMs, scarce NFC acceptance infrastructure, etc. In this article, we focus on four factors that depend on the technical architecture, and therefore serve as our drivers to change it:

• In the context of SIM-based M-NFC-Ss, the Wallet takes the relevant position from the perspective of the end user. Therefore, it acts as the important control and access point in the relationship with the end user [41]. Insufficient access to and control of Wallet services by SPs involved in SIM-based M-NFC-S initiatives has potentially negative implications for the SPs in terms of branding, customer relationship, monetisation of customer data, etc. A representative for digital commerce from Capital One said that the Wallet used in the Isis/Softcard initiative in the US offered too little control as it required banks to load their cards in the MNOs’ Wallet [71]. The same complain contributed to put off some banks from the initiative Semble in New Zealand [69].

• Arthur D. Little [4], based on feedback from several practitioners involved in SIM-based M-NFC-S deployments, indicated that increased interoperability is the single most important enhancement that is required from TSMs to enable the success of NFC. Possible causes for lack of TSM interoperability are immaturity of specifications, variety of vendors in the market, undefined business models (e.g. resulting from conflicts on insufficient access to and control of Wallet services), etc. Particularly after the launch of Apple Pay, the disbelief in current TSM technology can be illustrated by a statement from the former CMO for the deceased Isis/Softcard in the US: “They (MNOs) need to race towards where Apple went in order to get there quickly ... They can’t continue to propagate a solution (with TSMs) that doesn’t make sense” [66].

• While studying factors influencing the slow rate penetration of NFC mobile payments in western Europe, Apanasevic [3] concluded that the inability of actors to negotiate and share responsibilities becomes a reason of delay in the emergence of a new market. Examples of responsibilities that need to be shared are commercial relationships with third party SPs, customer care, contract establishment, billing, reporting, etc. Not only B2B roles need to be defined (i.e. which role a business actor can take in the emergent market relatively to another business actor), but also the implementation of the B2B roles and their interfaces (i.e. the B2B processes) need to be defined and implemented. One example of a B2B process that needs to be implemented is incident management. Referring to incident management, a representative from Capital One in US, stated: “When you have multiple TSMs, when you have a situation where there’s a secure element, there’s an MNO, there’s a TSM for the secure element, there’s a TSM for us; when things go awry, it’s hard to pinpoint who’s at fault” [55].

• de Reuver et al. [8], in a study of the TRAVIK/Sixpack mobile NFC payment project in the Netherlands, pointed out that the involved MNOs gave more importance to financial issues than the involved SPs due to: (1) lack of investment capital available in the MNOs; and (2) while the SPs had mainly a strategic interest on NFC, the MNOs were interested in obtaining tangible revenues. The higher importance of the financial domain for MNOs relatively to SPs has been corroborated in [4], where it was mentioned that, for MNOs, change of the TSMs cost model was the second most important enhancement required in order for NFC to succeed, while for SPs it was only in the fifth position. An insufficient return on investment was the reason provided by T-Mobile to drop out of the TRAVIK/Sixpack project in the Netherlands. The initiative’s program manager stated that “They (T-Mobile) expected profitability sooner and sooner (...) There is a chance the (joint venture) company would not be profitable at all” [47].

5 Alternative Architecture

Our alternative architecture is derived from four separate proposals, which are described in this section. Figure 3 illustrates the logical dependencies between the proposals with each other and between the proposals and the drivers for change introduced in the previous section. Proposals 1, 2, and 3 address directly and respectively the drivers for change insufficient access to and control of Wallet services, lack of TSM interoperability, and large scale capital investments by MNOs. Proposals 1 and 3 motivate proposal 4. Proposals 1, 2, and 4 contribute directly to address the definition and implementation of B2B processes. At the end of the section, a figure resuming the alternative architecture is presented.

Fig. 3

Main logical dependencies between the proposals with each other and between the proposals and the drivers for change

5.1 Proposal 1: Eliminate the Wallet

The Wallet as a concept in the digital world is now widely spread [40]. It was introduced as an analogy to the conventional leather wallet. The most obvious implication of this analogy is to perceive the Wallet as a container of cards just like in the physical world. A plastic card in the physical world has less value than its counterpart in the digital world (e.g. dynamic instead of static display capabilities, see Fig. 4 from the initiative Valyou in Norway). Therefore, applying the concept of card to the digital world is too limiting. In practice, we find digital functionalities with some elements to resemble plastic cards to facilitate the transition of end users from plastic cards to their digital counterparts (e.g. shape, see Fig. 4). The digital functionalities are implemented through MAs. As the concept of card does not translate well into the digital world then the concept of Wallet, in practice, works as a container of digital functionalities that are implemented through MAs. This makes it difficult to understand what distinguishes a Wallet from any other MA. Consequently, a large variety and number of MAs have been called Wallets (e.g. coffee company MAs such as one from Starbucks [13], bank MAs such as Chase Pay from JP Morgan [14], and transport company MAs such as one from Uber [87]).

Fig. 4

An example of a Wallet screen from the initiative Valyou in Norway

The fact that each person only carries one physical wallet could possibly be used to establish the distinction between Wallet and other MAs. Thus, if we could find, in a mobile handset, only one instance of a specific type of MA with functionalities resembling plastic cards then that instance could possibly be called a Wallet. This uniqueness within the mobile handset would have to be enforced technically at least by the OS if not by hardware. For example, in iPhone 6, only Passbook/Apple Wallet has access to the NFC interface. This makes Passbook/Apple Wallet unique within all MAs in iPhones, and therefore was possibly one of the motivations that led Apple to rename Passbook into Apple Wallet. However, nothing mandates a Wallet to use the NFC interface. For example, the MA from Starbucks for iPhones, which also has been called a Wallet [13], does not use the NFC interface but Quick Response (QR) codes. Moreover, limiting the access to the NFC interface to one MA might turn out to be too limiting for iPhones to realise the full potential of their NFC interfaces. Therefore, it is questionable if Apple should maintain this constraint in the future. In Android, which holds 82.8% of the mobile handset OS market share [34], no such strict technical enforcement has been put in place. Without a clear and widely applicable distinction from other MAs, the Wallet as a concept is limited, and has more potential to raise confusion than to help.

As described in Sect. 3, the Wallet is expected to be open in the sense of allowing a large number of SPs to offer new services in the Wallet in a flexible and agile way. To enable openness in the Wallet, the architecture Wallet/Widget needs to be implemented so that SPs can develop and deploy their Widgets in the Wallet as independently as possible from the Wallet Provider. Otherwise, SPs are constrained by the Wallet Provider (e.g. resources and priorities), the scalability in terms of number of Widgets in the Wallet suffers, and openness cannot be guaranteed in practice. However, the implementation of the architecture Wallet/Widget is problematic due to the following reasons:

• 1. Each initiative typically needs to develop its own customised Wallet solution. For example, Helixion developed a bespoke Wallet for Tapit in Switzerland [31], and C-SAM developed the Wallet for the Isis/Softcard initiative in US [52]. There are multiple reasons for the inexistence of off-the-shelf Wallet solutions. For example, lack of standardisation, market immaturity (perceivable e.g. by the number and immaturity of Wallet Provider companies), fragmentation of requirements (e.g. each initiative typically has its own design and branding), and general product immaturity (e.g. due to relatively low market demand for Wallet products). Even within one initiative, multiple Wallet versions may need to be developed. For example, in Google Play, it is possible to find three different Wallet applications for Semble, one for each of the three MNOs involved in the initiative in New Zealand.

• 2. Wallet development is complex, which forces initiatives to go through long development periods. For example, the initiative Isis/Softcard in the USs replaced C-SAM by Mutual Mobile even after a long development period and heavy investments on C-SAM’s Wallet [52]. Some of the problems observed suggest that C-SAM’s Wallet was still far from maturity: “Three out of five times it freezes on the PIN screen and needs to be restarted ... One out of five times, it just won’t open and needs to be forced closed to work”. Without being able to deliver a solution that is mature and attractive enough from an end user point of view, it is questionable if a Wallet Provider is able to prioritise the development of the Wallet/Widget architecture. Without being attractive from an end user point of view, the Wallet is not attractive to SPs, which makes the Wallet/Widget architecture irrelevant.

• 3. Due to the failure of several SIM-based M-NFC-S initiatives, Wallet Providers are not getting enough time to mature their solutions. For example, just before it was shut down, 13 months after its commercial launch, the initiative Valyou in Norway was reportedly close to launch a second version of its Wallet [65]. Facing a scenario of a complex bespoke development with tight time constraints, it is problematic for Wallet Providers to reach a level of maturity in their solutions which would allow them to consolidate the internal Wallet design, develop the general execution environment for Widgets, abstract it through an Software Development Kit (SDK) that could be made available to SPs, and prove in practice that their solution can indeed be considered open, particularly under expectations that could be up to the level of openness provided by an OS to MA developers.

• 4. Finally, the Wallet/Widget architecture should not just be open to SPs, but it should allow SPs to have some degree of flexibility to differentiate between themselves and compete on the level of the service that they offer to end users. For example, a payment Widget may distinguish itself by presenting the balance available and the list of transactions performed (see Fig. 4), by requiring less PIN entries due to an implementation of a more advanced risk management mechanism [75], by dynamically presenting offers that users can redeem in specific merchants, etc. The demand for flexibility in Widget development to allow competition between SPs increases even further the complexity to implement the Wallet/Widget architecture.

As described in Sect. 3, a quality that Wallets should have is that they should be ubiquitous and accepted at most merchant locations, and across a multiplicity of different terminals. Given their limited spread in terms of usage, it is unrealistic to think that, at least in the short-term, one Wallet (or one Wallet specification if this becomes defined) would be able to impose itself to become widely accepted by merchants, although exceptions exist in special institutional settings and for specific types of service (e.g. MobilePay in Denmark). In general, merchants are the ones that need to be accepted by Wallets. For payments, merchants can comply to the EMV specifications, which facilitates their wide acceptance by Wallets that comply to the same specifications. However, complying to standard specifications such as EMV is not an exclusive feature of Wallets, and therefore any MA can do it. For other types of service (e.g. loyalty, transport, and ticketing), the fragmentation of implementations is much larger, which complicates even more the acceptance of merchants by Wallets. Therefore, a quality that is expected to exist in Wallets, to be ubiquitous and accepted at most merchant locations and across a multiplicity of different terminals, is to a large extent unrealistic and, in the extent that is actually possible, is not an exclusive quality of Wallets.

Another common justification for the existence of Wallets is to provide a consistent experience for the end user regarding design, branding, and functionality, particularly regardless of the mobile handset it is running on. Consistency can be a concern due to two main sources of inconsistencies: (1) inconsistent business requirements from the different parties responsible for the Wallet (e.g. payment experiences substantially different between banks could confuse end users); and (2) inconsistent Wallet behaviour due to different implementations per OS, or due to different implementations of OS version, handset model, handset manufacturer, handset firmware, etc. (1) has not been a concern for SPs, and actually SPs have been pushing precisely in the direction of more control and flexibility in the Wallet [69, 71], which is one of the main selling points of HCE for banks [5]. Regarding 2), the market of OSs for mobile handsets is strongly dominated by Android (82.8%) and iOS (13.9%) [34]. Thus, there is little necessity to develop Wallets for less relevant mobile OSs such as Blackberry and Windows, and therefore to cope with inconsistencies between multiple Wallets developed for different OSs. Moreover, guaranteeing consistent MA behaviour independently of the OS version, handset model, handset manufacturer, handset firmware, etc. is a core concern for any OS. Therefore, due to the abstraction provided by an OS, there should be little inconsistencies in the Wallet behaviour between different OS versions, handset models, handset manufacturers, handset firmwares, etc. Minor inconsistencies that may exist surely must disappear in time with increased maturity of the OS, and increased importance of the functionalities required by SIM-based M-NFC-Ss (e.g. the NFC API from Android was subject to a major upgrade from version 4.3 to 4.4 to introduce HCE). Nevertheless, some initiatives have published lists of supported mobile handsets (e.g. Semble and Valyou). These lists do not necessarily exist because an OS is not able to provide a consistent experience for the end user between mobile handsets with relatively minor technical differences (e.g. different OS versions). The lists of supported mobile handsets can be provided simply to indicate, implicitly or explicitly, major technical requirements (e.g. the need for a mobile handset to have a NFC interface). However, there are reports of initiatives that test their Wallets for various Android handset models to guarantee a consistent experience for end users [69]. Therefore, (2) may still be a justification for the existence of Wallets, but certainly on a very technical level and with the tendency to disappear as Android and iOS mature, particularly on the functionalities specifically required by SIM-based M-NFC-Ss.

Finally, the introduction of the Wallet raises several complications:

• As it is a very specialised software product for a market that is still a niche, only a handful number of companies have developed or still develop Wallets as commercial products. Consequently, a SIM-based M-NFC-S initiative becomes highly dependent on its Wallet Provider. These are naturally relatively immature companies due to the lack of maturity of the market in which they operate. Due to their immaturity, size, and market demand, they are strongly dependent on their existing customers. For example, Helixion only advertises two customers: Tapit, the initiative in Switzerland which was shut down, and Alpha Bank, a Greek bank [32]. Toro, as another example, advertises customers from the Valyou project in Norway, which was also shut down, T-Mobile in Poland, and CIC, a French bank [92]. Consequently, Wallet Providers become susceptible to bankruptcy and buy-outs, which carry high risk for the SIM-based M-NFC-S initiatives that they serve. For example, C-SAM was bought by Mastercard [85], Corfire by Mozido [86], and Vivotech products have been acquired by Sequent [36].

• As the Wallet is typically offered by a separate company (e.g. not by the same company that provides the TSM), it requires a substantial amount of extra work and resources from an initiative specifically to manage the Wallet Provider. For example, specific Request For Information (RFI) and Request For Proposal (RFP) calls need to be issued to select a Wallet Provider, and a specific contract needs to be agreed upon containing aspects such as quality guarantees, delivery timelines, risk management, warranties, prices, payments, liabilities, intellectual property rights, insurances, compliances with laws and regulations, etc. The delivery of the solution requires setting up a project that has (e.g. people, schedules, and test environments) or may have many specificities to the Wallet Provider (e.g. geographical location, conferencing tools, and cultural backgrounds), which can heavily stress the collective action in place for the initiative [8, 84]. Finally, during the operation of the service, a Wallet Provider has its own B2B processes for customer care, billing, reporting, change management, incident management, etc.

• The Wallet introduces one additional layer of GUI which has limited value for most of the interaction between the end user and M-NFC-Ss. During usage of a M-NFC-S with a Wallet, in order to reach the GUI that is specific to the service of a SP, an end user needs at least to click on the Wallet icon in the OS (see Fig. 5a) and select the service of the SP (see Fig. 5b) in order to reach the Widget which implements the specific M-NFC-S (see Fig. 5c). Without a Wallet, the same process could be shortened by having a MA of the SP specifically implementing the M-NFC-S. One argument to introduce the Wallet’s GUI is that it can be used by end users to discover new M-NFC-Ss. This argument has limited value because an end user is exposed much more to usage than to discovery of M-NFC-Ss. Furthermore, it is questionable the value of a discovery service in the Wallet. First, because it necessarily can only discover services for one specific Wallet, which may be little in absolute number or relatively to the total number of M-NFC-Ss potentially available to the end user (i.e. by all Wallets available). Second, because the discovery service only makes sense if the Wallet exists. Thus, the value of the discovery service of the Wallet is conditional to the existence of the Wallet, which should be justified by other motives not the discovery service alone, and to the success of the Wallet in terms of number of M-NFC-Ss that it can offer, which by current standards is little. Finally, there are more familiar alternatives to help end users finding M-NFC-Ss (e.g. Google Play or websites of the SPs).

• Typical SPs present in Wallets have their own MAs (e.g. mobile banking applications), which raises the discussion of what services from a SP’s MA should be present in the Wallet and vice-versa. Replicating all services in both platforms is costly, redundant, and penalises the platform that is under full control of the SP (i.e. the MA) to favour one that has shared ownership (i.e. the Wallet). One example of a challenge in this discussion is the fact that a Widget is conceptually seen as analogue to a plastic card, whereas a MA is typically managing a customer account (i.e. with one or multiple plastic cards associated to it). Thus, the services offered in the MA may not apply directly to Widgets. For example, in a mobile banking application, it is more natural to present the balance available in a customer account, whereas in a Widget it is more natural to present the balance available in a plastic card (e.g. credit). On the opposite direction, it is complicated to communicate to end users why services from a SP are not all being presented in the MA of a SP, but are being dispersed between a Wallet and a MA.

Fig. 5

Example from the Valyou initiative in Norway of the usage of a M-NFC-S

Table 1 Resume of the arguments to eliminate the Wallet

Table 1 resumes our arguments to eliminate the Wallet, particularly their direction of support for types of materialisation of the Wallet: concept, product, company (i.e. the Wallet Provider), GUI (e.g. as seen in Fig. 4), and technical feature. The directions of support are negative (i.e. argument is against materialisation) or positive (i.e. argument favours materialisation). Our discussion is unequivocal regarding the proposal to eliminate the Wallet, particularly as a concept, as a product, as a company, and as a GUI. Obviously, the functionalities and GUIs of the M-NFC-Ss still need to exist. These must be implemented in the MAs of the SPs. The technical ability to cope with inconsistent behaviour caused by an OS or its underlying technology might still need to be dealt with. If that proves to be the case, such technical feature should be addressed by companies (e.g. TSM provider or SPs) and products (e.g. SIMs or MAs from SPs) that are, contrary to the Wallet and Wallet Provider, essential in a SIM-based M-NFC-S initiative.

Not necessarily due to all the reasons presented here, but the proposal to eliminate the Wallet has been taken to practice at least in one SIM-based M-NFC-S initiative: EnStream in Canada. A representative from EnStream expressed a strong belief that SPs “have strong desire to maintain their branded relationship with their customers ...(and EnStream will not) ... stand in their way (by offering its own Wallet application)” [53]. EnStream validates the technical feasibility of our proposal to eliminate the Wallet. Within non-SIM based initiatives, the high interest in HCE [68, 78] supports the belief of EnStream’s representative. The proposal to eliminate the Wallet serves also as a differentiator factor against Passbook/Apple Wallet, a solution that provides very little access and control of branding, design, and functionality to SPs.

5.2 Proposal 2: Centralise the TSM Functionality

Figure 1 indicates the potential sources of TSM interoperability issues: the interface between the SP and the SP-TSM, the interface between the SP-TSM and the MNO-TSM, and the interface between the MNO-TSM and the MNO. Following our proposal to eliminate the Wallet, the interface to the Wallet Provider is no longer taken into account. From the point of view of scalability of a SIM-based M-NFC-S initiative in terms of number of SPs and MNOs, as Fig. 6 illustrates for limit scenarios with five SPs and two MNOs, the decentralisation of the TSM functionality is a detrimental technical factor, even under the assumption of comparable complexity to implement each interface. This can hardly be a surprise as the need to centralise the TSM functionality was one of the key drivers to define the TSM role [18], and move away from decentralised TSM infrastructure proposals (e.g. in [1]).

Fig. 6

Decentralised versus centralised TSM functionality

The reality is that the interface between the SP-TSM and the MNO-TSM is likely more complex to implement than the interfaces between TSMs and SPs or MNOs. The reasons are: (1) as explained in Sect. 3, interfaces between TSMs have only been subject to partial standardisation; and (2) interfaces between SP-TSMs and MNO-TSMs are often established by different companies, i.e. competing TSM providers, which naturally may have conflicting interests that undermine the joint realisation of the interfaces. Referring to the French project Cityzi, [51] stated that “after years of work drafting and agreeing to detailed specifications and rules, the French ecosystem still has had difficulty proving it can be interoperable ... doubts were such that French telcos and banks felt it necessary not only to have written assurances of interoperability from the two vendors (i.e. Gemalto and Oberthur) but also to hold meetings with them to specifically discuss the topic”. Additional evidence of interoperability problems between different TSM vendors can be found in [4, 49, 50, 58, 64]. If the decentralisation of the TSM functionality is a detrimental technical factor, why is it being done? A list of possible reasons is:

• Potential market of individual SPs and MNOs is larger than the market of joint initiatives between SPs and MNOs (e.g. Moneta, Tapit, Valyou, EnStream, Isis/Softcard, etc.). Therefore, purely from the commercial perspective of selling TSMs, it makes sense for a TSM provider to prioritise the development of the products that are more specific and fit to the requirements of individual SPs and MNOs, i.e. SP-TSMs and MNO-TSMs, instead of centralised TSMs that appeal more to joint initiatives but less to individual SPs and MNOs. Moreover, as each vendor typically has both solutions, a centralised TSM offer can still be made by each vendor by combining its SP-TSM and MNO-TSM with a higher degree of centralisation (i.e. centralised within the same company, but technically still split). However, such offer may be short-sighted as the technical split can still introduce scalability problems, although managed within the same TSM provider. For example, the initiative ADTC in Taiwan was delayed by months partially because the vendor Safran Morpho underestimated the challenges of integrating five MNOs with its TSM technology [72].

• SPs and MNOs may opt to have its own TSM to have the freedom to connect to any TSM instead of connecting to one TSM and depend on it for third-party TSM connections. This decision assumes that a decentralised TSM infrastructure may evolve. However, there are many evidences that suggest that such scenario is unlikely. For example, the inherent complexity of TSM processes [59], initiatives such as Isis/Softcard in the US that took actions to centralise the TSM infrastructure [63], high costs involved on hiring TSM services [58, 62], and the failure of several initiatives based on TSMs (e.g. Tapit, Valyou, Isis/Softcard, etc.).

• SPs may opt to hire their own TSM to compensate for a general lack of trust that often is present among SPs or between SPs and MNOs [8, 30, 84]. This option can be motivated by the assumption that having its own SP-TSM is required to control critical key management functions for the credentials of the end user, and thus reduce concerns that other parties may misuse them or simply not protect them enough (e.g. MNOs may be less concerned about fraud than banks, and consequently secure their systems less [30]). Such assumption is wrong, but could easily be made in a context of limited knowledge about TSMs and by associating the term trusted in TSM with critical key management functions for the credentials of the end user [18]. However, the only FG dealing with critical key management functions for the credentials of the end user is the PSM, which can be performed both by the SP or by the SP-TSM.

• From a commercial perspective, a TSM vendor can generate revenues from the provisioning or installation of TSMs (e.g. charging for installation licenses to SPs and MNOs), or from their usage (e.g. charging for number of M-NFC-Ss installed by end users). The former commercial model benefits from the split between SP-TSM and MNO-TSM. Given the little success of SIM-based M-NFC-S initiatives so far, and prospects for their potential success in the near-future [77], it makes sense for TSM providers to rely mainly on revenues from the provisioning or installation of TSMs. There are evidences that this has been the case with reports of US $4 million or $5 million just to buy a license and equipment for a TSM product [56]. One of the largest TSM providers, Gemalto, had its revenues considerably lowered after the closing of the Isis/Softcard initiative in US, although the initiative had little usage by end users [60], which suggests that Gemalto was getting its revenues from provisioning or installation of services (i.e. TSM and others). If indeed TSM vendors rely mainly on generating revenues from the provisioning or installation of TSMs, then they have a strong motivation to promote and reinforce the split between the SP-TSM and the MNO-TSM.

• A TSM provider is typically also a provider of OTASs (e.g. Gemalto, G&D, and Oberthur). Due to the synergies between a TSM and a OTAS (see Fig. 2), it is natural that TSM providers leverage on TSMs to sell OTASs and on OTASs to sell TSMs to MNOs. As described in Sect. 3, MNOs typically prefer to hold the OTA functionality, particularly because the OTAS has broader applications than just TSM services. Under this scenario, it does not make sense to involve SPs, as parts of the agreements concern only MNOs (i.e. the OTAS operations that are not serving TSM services). Consequently, SP-TSMs are out of such agreements for combined offers for OTASs and MNO-TSM services. Two examples of such agreements have been made by the vendor G&D [43]. Commercial synergies between MNO-TSMs and OTASs (that exclude SP-TSMs) also promote and reinforce the split between SP-TSMs and MNO-TSMs.

Independently of the possible motivations to do it (i.e. commercial motivations by TSM providers, and misinformed or unrealistic assumptions by SPs and MNOs), the split between SP-TSMs and MNO-TSMs is a detrimental technical factor for the scalability of a SIM-based M-NFC-S initiative in terms of number of SPs and MNOs, particularly if it is done between different TSM providers. Therefore, we propose to centralise the TSM functionality in the following senses: (1) within the same company, i.e. to have only one TSM provider for every initiative; (2) within the same product and commercial offer (i.e. to sell broadly a TSM service instead of fragmenting the commercial offers between SP-TSM and MNO-TSM); and (3) within the same technical application (e.g. one Java application fully implementing all TSM functionality instead of having two Java applications, one implementing the SP-TSM functionality, and the other implementing the MNO-TSM functionality, communicating with each other using GlobalPlatform messages). This proposal has the secondary benefit of reducing the number of involved companies, and therefore requires less work and resources specifically to manage multiple TSM providers, reduces fragmentation of B2B processes across multiple parties, etc.

Due to the large investments and development work required to make a TSM operational (e.g. reports point at US $4 million or $5 million just to buy a license and equipment [56], and six months of development work [74]), it is necessarily difficult to reverse the split between SP-TSMs and MNO-TSMs after it has been applied. For example, in the initiative EnStream in Canada, although the three larger banks part of the initiative (i.e. CIBC, RBC, and TDBG) had already hired their own TSMs, EnStream decided to launch its own SP-TSM service to facilitate the on-boarding of additional banks. When the new service was launched, EnStream announced the three larger banks as potential customers [54]. One year later, none of these banks had yet decided to use EnStream’s SP-TSM [64]. Similar case happened with the initiative Isis/Softcard in US [57]. In this regard, the TSM infrastructure manifests properties of path dependence [38], i.e. an apparently minor or fleeting option or a seemingly inconsequential decision that leads to decentralise the TSM infrastructure can have important and irreversible influences on the success of the platform. Therefore, it is important that not only the right constraints and motivations are put in place to centralise the TSM functionality, but they should be present from the start of the initiative.

5.3 Proposal 3: Use OTI Instead of OTA

As mentioned previously, commercial synergies between MNO-TSMs and OTASs promote and reinforce decentralisation of TSM infrastructures, and therefore hinder TSM interoperability. Moreover, as the OTA functionality is typically taken by the MNOs, it contributes to the large scale capital investments that MNOs need to take in SIM-based M-NFC-S initiatives. Given these two disadvantages, if there are two possibilities to remotely manage data and applications in a mobile handset (i.e. OTA and OTI), why is SS being done using OTA and not by OTI?

The most obvious reason is that a mobile handset is more likely within reach of a OTA bearer (e.g. a 3GPP bearer) than a OTI bearer (e.g. Wifi or a 3GPP bearer with mobile data usage active). However, it is questionable that the improved connectivity provided by OTA relatively to OTI is relevant enough to justify its use. Common MAs (e.g. from Youtube and Facebook) rely satisfactorily only on OTI, independently of the communication mode used (i.e. push versus pull), and typically have much heavier requirements of load than M-NFC-Ss, which are maximum in the order of tenths of kilobytes to install one service [15]. We could still argue that certain M-NFC-Ss, such as payments, are more prone to security threats and liabilities than services provided by other MAs. Therefore, even if residual, connectivity improvements brought by OTA could still be valuable, particularly for banks facing scenarios of lost or stolen mobile handsets containing payment cards. This argument has three problems. First, the general problem of lost or stolen payment cards is already well-known to banks independently of if the payment cards exist in mobile handsets or in plastic form. Given that an OTA or OTI-like mechanism does not exist in plastic form and that banks have been managing lost or stolen plastic payment cards for a long time, it is unlikely that, in this regard, banks value OTA substantially, particularly the improved connectivity provided by OTA relatively to OTI. Second, the potential consequences of a lost or stolen payment card are likely smaller if the payment card exists in a mobile handset than if it exists in plastic form, because customers are statistically more aware of a lost or stolen mobile handset than they are of a lost or stolen wallet [93]. Third, even if the consequences would be the same, and admitting that banks would like to manage these consequences differently for mobile and plastic cards, OTA alone does not allow it, because an OTA channel can easily be switched off (e.g. by using flight mode), thus preventing a bank from reaching the mobile handset to lock or terminate its cards.

A second possible reason for the use of OTA instead of OTI is by making the wrong assumption that OTA is a necessary pre-condition to deliver TSM services. Such assumption could be established due to: (1) the level of technical knowledge required to distinguish OTA from OTI, and OTA or OTI from TSM functionalities (i.e. the SS functionalities); (2) imprecise use of the term OTA complicating its distinction from OTI (e.g. “OTA provisioning services introduce the need for a trusted service manager (TSM)” SIM Alliance [89]); (3) frequent one-to-one association between OTA and TSM suggesting that a TSM is always accompanied by an OTA platform (e.g. “the TSM infrastructure can be regarded as a ’general purpose over-the-air (OTA) personalisation system” [27]); (4) as mentioned in Sect. 3 [24] essentially equates SS to OTA; and (5) commercial implementations sometimes merge TSM and OTA functionalities (e.g. in G&D’s MNO-TSM [17]).

A third possible reason for the use of OTA instead of OTI is historical. In the past, end users had to rely on their MNOs to buy and download MAs (known as the walled gardens). From the perspective of maintaining this role, it could have been justifiable for MNOs to opt for OTA as it provided them with more control than OTI. This justification was still strong when GlobalPlatform started its standardisation activities on SIM-based M-NFC-Ss. For example, [18] included ambitious predictions on the potential number of MA downloads using OTA. However, in a general sense, the role of MNOs as MA distributors is no longer relevant as the launch of OS specific application discovery stores (Google Play and App Store were launched in 2008) reduced the MNOs’ leverage and control of the software in mobile handsets and gave end users options and capabilities that were unavailable through the MNOs’ platforms [33].

The fourth possible reason for the use of OTA instead of OTI is that OTI requires a Proxy functionality that is able to forward scripts from a TSM to the SIMs [23, 45]. Such Proxy must be installed on the OS of the mobile handsets. Following the architecture of Fig. 1, the logical place to implement the Proxy is in a Wallet. Thus, before the TSM can start managing a SIM, it must wait for the end user to install the Wallet implementing the Proxy. With OTA, the TSM has the possibility of managing the SIM even before the Wallet is installed. The benefit of this possibility is to pre-install Applets so that, when the end user tries to install the Applets’ correspondent M-NFC-Ss, only the Widgets are still left to be installed. As the installation time of the Applets can be in the order of minutes [70], their pre-installation can have a significant positive effect for the end user. However, these positive effects only exist for the first M-NFC-S installed in the Wallet because, for the subsequent services, the Proxy functionality is already present, thus allowing pre-installation of the correspondent Applets. Moreover, the positive effects only exist if the end user triggers the installation of the first M-NFC-S immediately or soon after the installation of the Wallet. Otherwise, between the Wallet installation and the installation of the first M-NFC-S, the TSM has time to pre-install the correspondent Applet. Furthermore, pre-installation of Applets is only feasible when the TSM is able to predict which services the end user may install first, and worthwhile if the SIM has enough memory to install most or all of the correspondent Applets. Finally, even under such circumstances, there are still two alternatives to OTA: (1) MNOs can pre-install Wallets if they control distribution channels of mobile handsets (e.g. Google paid a large amount of money to have Google Wallet pre-installed in mobile handsets shipped by Verizon Wireless, AT&T Mobility, and T-Mobile USA NFC Times, [63]); and (2) MNOs can pre-install the most common Applets in the SIMs in factory (e.g. the VMPA).

As the four reasons to use OTA do not justify its use, particularly relatively to the potential implications to TSM interoperability and potential investment costs to MNOs, we propose to use OTI to implement SS instead of OTA. As [24] essentially equated SS to OTA, we expect that most initiatives to use OTA instead of OTI, although this cannot be confirmed without detailed and inside information of each initiative. GlobalPlatform [23] and Munch-Ellingsen et al. [45] described the application of OTI to M-NFC-Ss but did not contextualise it as we do: (1) they have presented OTI mainly as a technical possibility; (2) they have not proposed OTI, from a general point of view, as a better alternative to OTA; and (3) they have not provided our arguments to compare OTA and OTI. The context that we provide to evaluate OTI relatively to OTA is our contribution to the work of [23, 45]. In the opposite direction, [23, 45] validate the technical feasibility of our proposal.

The TSM provider is the best candidate to implement the Proxy functionality. First, because the Proxy needs to technically integrate with the TSM, thus the Proxy can be naturally developed as an extension of the TSM. Second, because the functionalities of the Proxy are reusable by different SPs. Thus, for economies of scale, it is logical that the TSM provider develops the Proxy, and the SPs integrate the Proxy in their MAs (e.g. as a library).

5.4 Proposal 4: Motivate Elimination of the Technical Integration Between the TSM and the MNO

Following our proposal to use OTI instead of OTA, the technical integration of the TSM and the MNO for the services provided by the OTAS and the SMSC is no longer required (see Fig. 2). Furthermore, in a general sense, a DAMS of the MNO has little relevance relatively to OS specific application discovery stores, particularly for the discovery and download of MAs. In addition, following our proposal to eliminate the Wallet, functionalities and GUIs to use M-NFC-Ss are implemented in MAs of SPs, which are naturally under full control of SPs. If it is not used for discovery, download, and usage of MAs, then the DAMS of the MNO does not bring any value to the TSM. Consequently, the technical integration of the TSM and the MNO for the services provided by the DAMS can be eliminated as well.

The elimination of the technical integration between the TSM and the MNO for the purposes of the OTAS, the SMSC, and the DAMS, should motivate us to eliminate completely the technical integration between the TSM and the MNO, particularly because the integration between the TSM and the MNO has been pointed as one of the problems to deploy M-NFC-Ss. The case of Safran Morpho and ADTC in Taiwan, referred to previously in this article, serves as a possible manifestation of these problems [72]. Arthur D. Little [4] quoted a practitioner stating that “(to) simplify technical processes and integration into MNO systems” is a major enhancement required for SIM-based M-NFC-S deployments. To do so, we need to eliminate the dependency of the TSM from the DMSR, the SEIS, and the CCMS services provided by the MNO.

The DMSR serves DI and MSI requests. DI allows the TSM to check if the technical capabilities of the mobile handset are sufficient for the M-NFC-S. Examples of technical capabilities that may be verified are manufacturer, model, and existence of NFC chip [24]. As mentioned previously, the use of OTI instead of OTA forces the presence of a Proxy in the mobile handset to serve the TSM with OTI channels. The TSM could leverage on the same Proxy for DI. This solution has no negative implications for the eligibility check process, because the privileges in the OS to retrieve information about capabilities of the mobile handset are the same for the MNO and for the Proxy. However, this solution has one positive implication. As the TSM provider should be the provider of the Proxy, it can get more control over the DI process than under the solution that DI is offered by the MNO. Particularly, DI from the Proxy avoids that the TSM and the MNO need to maintain a common and updated list of static values to represent the types of mobile handsets in the market (i.e. the Device Capability Profile Identifiers [24]). Such list is difficult to maintain, particularly statically and collaboratively. Using the Proxy, the TSM provider may opt to maintain such list or find another way, not compliant with [24], to retrieve capabilities from the mobile handset.

Regarding MSI, the DMSR performs technical (e.g. is there any OTA bearer available?) and business eligibility checks on the mobile subscription. Regarding business eligibility checks, [24] stated that these are business process dependent, thus specific to each MNO, and only provided one example (i.e. has the end user subscribed (in general) to M-NFC-Ss?). We can classify business eligibility checks in three types: (1) is the end user customer of the MNO?; (2) has the end user subscribed (in general) to M-NFC-Ss?; and (3) is the mobile subscription from ... the MNO/ ... a data package/ ... a barred customer/ ... a number secret/ ... a pre-paid package with zero balance/ ... etc.? Types 1 and 2 are not mobile subscription specific, but use the mobile subscription (specifically the MSISDN) to identify the customer within the MNO. Type 3 is mobile subscription specific. With the proposal to use OTI instead of OTA, the mobile subscription is no longer technically required. Therefore, we can argue that checks of mobile subscription technical eligibility and business eligibility of type 3 can be dismissed because they are emptied of technical justification. To address the business eligibility of type 1, we propose the TSM to use a combination of technical eligibilities over the SIM to check if the SIM belongs to the MNO (e.g. is the SIM personalised with certificates that are specific to the MNO?). Without integrating with the MNO, there is no way for the TSM to check if the end user is (still) an active (e.g. paying) customer of the MNO. However, we argue that this check is not relevant because it is unlikely that an end user uses a SIM without an active mobile subscription just because of M-NFC-Ss, particularly while these have little relevance. We can apply the same argument to empty the importance of the business eligibility check of type 2: it is unlikely than a MNO can charge end users specifically for having M-NFC-Ss while these have little relevance. If M-NFC-Ss become significantly relevant relatively to the mobile subscription, the TSM and MNO can consider to establish a technical connection between them specifically for addressing mobile subscription business eligibilities of types 1 and 2. For MSI, the DMSR has one final function, which is to convert the MSISDN from or to the ICCID (e.g. see Fig. 2). However, as the mobile subscription is no longer used for any purpose then this conversion is no longer required. By emptying the importance of DI and MSI from the MNO to the TSM, we eliminate the technical integration between the TSM and the MNO for the purposes of the DMSR.

The SEIS serves two purposes: (1) it allows the TSM to convert a MSISDN to a ICCID; and (2) it allows the TSM to retrieve a SE Capability Profile Identifier GlobalPlatform, [24]), which indicates the technical capabilities of the SIM (e.g. NFC capable). Regarding 1), as discussed, the MSISDN is no longer relevant in general, but it could still be used as the first identifier to trigger the installation of a M-NFC-S (and later converted to a ICCID). However, this is not a good solution. Assuming the likely scenario that the installation is triggered from the mobile handset, the MSISDN is not technically available in the OS, thus it needs to be manually introduced by the end user. This is an unnecessary burden when the ICCID is technically available in the OS, and can be used as an identifier between the TSM and the MNO. Regarding 2), we propose to replace the SE Capability Profile Identifier retrieval by some combination of technical eligibility checks by the TSM to evaluate if the SIM is capable to support the M-NFC-S (e.g. is the SD selectable via the Proxy?). This option avoids the need to maintain a common and updated list of static values for SE Capability Profile Identifiers between the TSM and the MNO. While easier than the list of Device Capability Profile Identifiers, such list is still difficult to maintain.

Dual Mode for CCM has to be used to eliminate the technical integration between the TSM and the MNO for the purposes of the CCMS. The implication of using Dual Mode is that the MNO loses the ability to technically control each CCM action in the SIM. This is not necessarily a problem if the TSM is, both formally and practically, a trusted party for the MNO, which is essentially what it is supposed to be. Thus, Dual Mode requires that well defined business agreements exist between the TSM and the MNO (e.g. defining precisely the boundaries for the technical actions of the TSM in the SIM), and that the TSM is technically operating as the business agreements predict. In addition to Dual Mode, the SIM needs to be personalised in factory in such a way that SIM specific actions do not need to be taken for security management (e.g. by using CCCM Scenario #2.B GlobalPlatform [25]) and SEAC rules change (e.g. by using the concept of ARA-C GlobalPlatform [20]).

By eliminating the technical integration between the TSM and the MNO, we get substantial benefits for the B2B processes. In general, we reduce the technical involvement of the MNO and the fragmentation of technical functionalities between the TSM and the MNO. Consequently, the B2B processes in the TSM and in the MNO become simpler to implement. From the MNO point of view, our proposal implies that no technical changes need to be made in the MNO to support M-NFC-Ss with the exception of the ones done in factory to the SIMs. Thus, changes required to B2B processes in the MNO are minimised, and possibly even avoidable. From the perspective of the TSM, as the number of technical possibilities is reduced significantly, the implementation of the B2B processes becomes simpler. For example, the billing process from the MNO to the TSM most likely needs to be adapted differently to OTA and OTI (e.g. higher costs for OTA). The cumulative benefits obtained between each component (e.g. OTAS, SMSC, and DAM) and each B2B process (e.g. incident management, reconciliation of data, and change management) are likely substantial.

5.5 Resulting Architecture

The application of the four proposals to the current architecture (described in Sect. 3) results in the architecture presented in Fig. 7. All changes should be obvious with one exception: we propose GEI, PSM, and GSM to be requested from the SP to the TSM via the Proxy instead of directly. With this approach, GEI, PSM, and GSM are offered by the Proxy to the MA (e.g. as a library), which brings three advantages: (1) the SP only has one integration point instead of two with the TSM; (2) the integration development effort for the SP concentrates in the SP’s MA development unit, which is typically more agile and flexible than the development unit responsible for the SP’s backend servers; and (3) the SP’s backend servers are more isolated from required changes to support M-NFC-Ss, which contributes to their stability. In any case, the overall impact of this approach relatively to the impact of the four proposals should be small because it happens upper stream (i.e. the other proposals happen deeper in the infrastructure), it has less obvious business implications (e.g. it does not allow to lower the number of companies involved), it affects only the standardised interface between the SP and the TSM (e.g. simpler than the interface between the TSM and the MNO in the current architecture), etc. Therefore, we do not discuss this approach thoroughly as we do with the other four proposals.

Fig. 7

Alternative architecture for SIM-based M-NFC-Ss

6 Discussion

One of the criticism that can be pointed to our work is the representativeness of some of our claims. The ones that are justified by GlobalPlatform [22, 24] should not be matter of too much questioning (e.g. the distribution of the FGs, the use of OTA instead of OTI, and division between the SP-TSM and the MNO-TSM). However, the other ones should probably be matter of further validation, namely the following ones: (1) a M-NFC-S is typically composed by a combination of a Widget and an Applet; (2) MNOs typically prefer to hold the OTAS; (3) most often, the providers of SP-TSM and MNO-TSM services are different; (4) B2B processes of each actor are not technically integrated, and therefore require always manual intervention; (5) each initiative typically needs to develop its own customised Wallet solution; and (6) Wallet Providers are not getting enough time to mature their solutions. Nevertheless, validating the representativeness of these six claims should be relatively simple as it does not require deep technical investigations or serious commercial disclosures.

Particularly because of its potentially large benefits, we think our proposal to centralise the TSM functionality would benefit from further insights. Essentially, we have motivated the proposal with broad empirical evidences of the problem which sign the potential benefits (e.g. with the reference to the French project Cityzi), and with two non-technical arguments (i.e. only partial standardisation between TSMs, and TSM functionality typically being offered by different providers). As our proposal is technically rooted, we think it could benefit from having further insights on the technical mechanisms involved, and their positive impact. For example, if we centralise the TSM functionality, we reduce the number of different development, pre-production, and production environments at least by a factor of two. As another example, we are able to centralise the technical eligibility check mechanisms for mobile handsets. This a complex function due to the variety of mobile handsets in the market, not standardised by GlobalPlatform, and is reusable between TSMs. Therefore, it would be highly beneficial to centralise it.

The proposal to motivate the elimination of the technical integration between the TSM and the MNO would benefit from understanding the contribution of the OTAS, SMSC, and DAMS to the overall complexity of integrating the TSM with the MNO relatively to the contribution of the DMSR, SEIS, and CCMS. As the elimination of the DMSR, SEIS, and CCMS was justified partially by the elimination of the OTAS, SMSC, and DAMS, knowing their relative importance would help motivating the proposal. For example, on a basic level, we could evaluate the familiarity of the MNO with each one of the components to get a rough indication of their integration complexity (e.g. OTAS $\rightarrow$ familiar $\rightarrow$ low complexity, and CCMS $\rightarrow$ unfamiliar $\rightarrow$ high complexity).

Another aspect that requires further investigation is the impact of the alternative architecture to other operations than deployment (e.g. deletion/termination) and to events or situations that may have impact on the status of M-NFC-Ss (e.g. mobile handset change). For example, some use cases defined in [24] such as mobile subscription termination, suspension, and resumption, may not make sense anymore. Others might have their importance questioned, at least for some of the actors. For example, with OTI, it makes less sense to include the TSM in the scenarios of mobile handset lost or stolen by the end user. Finally, it is important to investigate how the alternative architecture can cope with some specific scenarios such as SIM renewal by the MNO.

From version 1.0 to 1.1, GlobalPlatform [24] defined, for example, the interface between the TSM and the SP (i.e. definition of GEI, PSM, and GSM). Thus, GlobalPlatform’s [24] version update from 1.0 to 1.1 would have had major impact in our work. From version 1.1 to 1.2, which is the most recent one, the main change was the introduction of DAM, thus it would have had some impact in our work. Naturally, changes in [24] should become less and less important. Nevertheless, we cannot rule out that the alternative architecture may need to be re-evaluated with coming new versions of [24].

Relatively to the current architecture, the alternative architecture brings important direct benefits. For example, it requires less actors (e.g. no Wallet Provider and only one TSM provider), less technical integration (e.g. no technical integration between the TSM and the MNO), less technical development internally in each actor (e.g. no OTA functionality required from the MNO), and is less disruptive relatively to existing services (e.g. relatively to existing MAs of SPs). In addition to the direct benefits, our alternative architecture brings also indirect benefits. For example, it simplifies the collective actions required to deploy SIM-based M-NFC-Ss (e.g. by simplifying governance and leadership, reducing conflicts and rivalry, facilitating trust to be established, and reducing the number of interdependencies between actors), and it reduces the risk of strategic conflicts between actors (e.g. between business units of each MNO, between MNOs and SPs, and between short-term and long-term objectives).

Each technical change proposed in this article is either described in specifications (e.g. in GlobalPlatform [24]) or has been already validated in practice (e.g. by Munch-Ellingsen et al. [45]). Moreover, it is unlikely that the combination of these changes raises any special technical challenge that deserves investigation. Therefore, from a scientific point of view, we do not think that our proposal justifies a technical validation. However, we do think it justifies to be validated in practice, i.e. as a commercial offer so that its advantages and disadvantages can be evaluated in a real institutional and market context. As this is not a simple task, an alternative is to compare it with HCE and Apple Pay, i.e. the two main technologies that compete in practice with the SIM-based approach. A rough analysis is enough to conclude that our proposal resembles more the implementations of HCE and Apple Pay than it resembles the orthodox implementations of [24] (e.g. in the sense of no technical integration required with MNOs). Therefore, we should expect that some of the disadvantages pointed to the SIM-based approach relatively to HCE and Apple Pay lose relevance or even disappear.

7 Conclusions

Although the number of initiatives remains large [29] and growing [76], prospects for the success of the SIM-based approach are waning [77]. Therefore, it is urgent to understand, and mitigate or correct the factors that have been limiting its success. Alternative technologies such as HCE and Apple Pay are also struggling [37, 44, 61, 67, 73, 77, 80,81,82], which increases the uncertainty in the NFC space. This uncertainty delays the consolidation of the technologies and decelerates their evolutionary pace, leading to increased fragmentation [78]. Our alternative architecture contributes to consolidate the SIM-based approach, and is therefore aligned with the efforts of SIM-centric associations such as GSMA that have recognised the need to cut as much as 75% out of the complexity involved in SIM-based M-NFC-Ss [59].