D3.3: Study on Mobile Identity Management

Study on Mobile Identity Management MOBILE IDENTITY AND WEB SERVICES

Mobile Identity and Web Services

The Internet has become a very common and natural way for business interactions and information exchange between organisations and among individuals. Nearly everyone is familiar with email and the World Wide Web. Web Services are the next step in this interconnected world. They bring the paradigm of service-oriented architecture in practice. They offer an interoperable framework for stateless, message-based and loosely-coupled interaction between software components. These components can be spread across different companies and organisations, can be implemented on different platforms and can reside in different computing infrastructures. Web Services can expose any useful functionality on the Internet via XML messages that are exchanged through a standard protocol, called SOAP. These message exchanges can happen in a secure, reliable and transacted way, between federated organisations, or between peer individuals. See (Cabrera, Kurt and Box, 2004; IBM Corporation and Microsoft Corporation, 2003) for more information. The Web Services federated security architecture is also discussed in the FIDIS study on a “structured overview on prototypes and concepts of identity management systems” (D3.1).

In parallel to the Internet growth, mobile communications have become an additional common way of interconnecting. There has been a vast penetration of mobile phones and devices over the last years. Most people have a personal mobile phone or mobile device. As these devices (or more accurately, the SIM, WIM or USIM, see section 2.3) have fixed identifiers, they are essentially providing a mobile identity. Mobile network infrastructures provide the means for authentication and billing of this identity.  

Bridging these two worlds would be advantageous. Mobile operators could then for example provide (web) services that give access to mobile services. Third party service providers could leverage the authentication and billing infrastructure of mobile networks, instead of setting up and maintaining their own identity management systems (e.g., usernames and passwords).  

The Mobile Web Services initiative (Microsoft Corporation and Vodafone Group Services Ltd., 2003) forms a motivational background for this study. Note, however, that the content of this section does not necessarily reflect in any way the technical roadmap or outcomes of this specific initiative. The combination of WWW and wireless security has also been explored in (Claessens, Preneel and Vandewalle, 2002). 

This chapter touches upon potential Mobile Web Services scenarios and specific associated privacy requirements. While the chapter points to some mechanisms and approaches with which these privacy goals can be addressed, complete architectures and solutions are out of the scope. 

Mobile Web Services scenarios

Figure 2-4 below describes the possible Mobile Web Services scenarios, which are largely based on, but not necessarily duplicating, scenarios described in (Microsoft Corporation and Vodafone Group Services Ltd., 2003). 

Figure 2-4: Mobile Web Services scenarios, based on (Microsoft Corporation and Vodafone Group Services Ltd., 2003) 

There are three entities participating: 

1. The Subscriber is a user who has a mobile identity token from a mobile network operator, either a pre-paid card, or mobile subscription. 

2. The Third-party service provider provides Web Services exposing specific business or entertainment value. The Third-party service provider has a business relationship with the Mobile network operator to leverage the mobile network authentication and billing infrastructure when the Subscriber wants access to the third-party web service. 

3. The Mobile network operator provides specific authentication and payment web services, as well as specific mobile network Web Services, such as SMS, MMS and location provision. The specific mobile network Web Services require the Subscriber to authenticate and optionally pay. 

For the purpose of this chapter, the Subscriber’s Client Application and Mobile Identity token are able to connect and exchange information in some way and are abstracted as one component. Both third-party services and mobile network services may interact with the mobile network operator’s authentication and billing infrastructure in the back-end (e.g., to settle payment). 

When a Client Application wishes to make a secure service request to either a Third-party Service or a Mobile Network Service, it may be required to obtain a Security Token (Sx) from the Authentication Service. When the Authentication Service receives a request to issue a Security Token, it will typically require a certain Service Context (Sc) of the service request being made, where the Service Context may for example detail the Mobile Network Service or Third-party Service the Client Application wishes to access. The Authentication Service will then issue a Security Token if it can successfully authenticate the Subscriber by using the Mobile Identity token authentication mechanism.

If the service request to either the Third-Party Service or Mobile Network Service also involves payment, the Client Application must obtain a Payment Token (Px) from the Payment Service, typically once it has obtained the appropriate Security Token. When the Payment Service receives a request to issue a Payment Token, it requires the Payment Context (Pc) of the service request being made, where the Payment Context may for example detail the payment amount required by the Third-Party Service or Mobile Network Service. The Payment Service will issue a Payment Token if it can successfully obtain payment authorisation from the Subscriber.

Note that the scenario in section 2.4 focuses on profiling of mobile customers by the mobile operator, for the purpose of offering mobile services where the data transmission cost may be covered by the service provider. We here discuss the use of the authentication and billing infrastructure of mobile networks for the purpose of authenticating to, and billing, Web services (offered by service providers as well as the mobile operator).

Privacy objectives related to billing/payment

In the billing or payment scenario the mobile operator effectively acts as the bank in a classical electronic payment system (Claessens, 2002), as indicated in figure 2-5. 

Figure 2-5: Classical electronic payment system applied to mobile network billing 

The Subscriber’s privacy requirements are generally related to the unobservability, untraceability and unlinkability of the Subscriber’s identity with respect to external observers as well as with the participating entities. These requirements originate from the electronic payment systems world (Claessens, 2002) and are also aligned with the generic anonymity requirements defined by (Pfitzmann and Hansen, 2004).

1. Unobservability – External parties should not be able to observe the Subscriber’s identity from ongoing Web Services interactions. If the Subscriber’s identity is not encoded in any of the security tokens or contexts, it cannot be observed. If it is encoded, then it should be confidentiality-protected by using the necessary Web Services security protections.

2. Untraceability – For a single transaction, neither the mobile network operator nor the third-party service provider should be able to trace the identity of the Subscriber in the context of a ‘payment’ or a ‘deposit’ transaction. This means that the Subscriber’s identity should not be disclosed from the Subscriber to the Service as part of using the payment token and from the Service to the Mobile Operator as part of depositing the token. This particularly also means that the mobile operator should ‘blindly’ issue a payment token, so that it cannot be linked to the Subscriber’s identity when it is later deposited by the service provider.

3. Unlinkability – The mobile operator or the service provider should not be able to link multiple transactions as originating from the same Subscriber.

There are other privacy issues besides the Subscriber’s identity. In case where the Subscriber’s identity is known by the mobile network operator and the service provider, then at least the specific service context (e.g., goods obtained through the service) should not be disclosed to the mobile network operator. 

In addition to the privacy requirements, there are a number of security requirements which need to be addressed at the same time. Most importantly these include the detection and/or prevention of double-spending. A complete overview of these security requirements is beyond the scope of this chapter. 

The generic Mobile Web Services scenarios as well as the Web Services security specifications allow the usage of custom token profiles which can leverage different types of electronic payment system structures. Orthogonal to (but sometimes dependent of) the privacy requirements, these can have different characteristics: 

1. The Subscriber can have a local or central account. If the Subscriber can obtain payment tokens which actually carry monetary value, the Subscriber can maintain a local account on his device. The payments can also directly come from a central account associated with the Subscriber and maintained by the mobile operator. Both pre-paid phone card and mobile subscription can support local and central account.

2. There can be pre-payment or post-payment. If the mobile network operator collects money from (or adds to the bill of) the subscriber at the time of withdrawing the payment token, we refer to pre-payment. If the subscriber gets a bill from the mobile network operator after the payment token has been deposited, we refer to post-payment. Both pre-paid phone card and mobile subscription support pre-payment. Post-payment is only possible with a mobile subscription.

3. Electronic payments can be on-line or off-line. A payment is on-line if the service provider has to deposit the payment token immediately after payment and before providing the service, essentially to verify if the payment will be covered. If the deposit can happen at a later point in time without the service provider needing to worry, we refer to an off-line payment transaction.

Privacy objectives related to authentication

While payment can be generalised into authorisation, authentication really refers to identity authentication. The privacy goals are therefore somewhat different.  

We particularly look more closely at the case of the third-party service provider, wanting to leverage the mobile network operator’s authentication service (e.g., an e-commerce service provider that wants to authenticate its customers, or an organisation that wants to authenticate its employees). 

We can identify the following potential privacy requirements: 

1. It may be required that the mobile network operator does not learn anything else but the mobile identity of the subscriber. The subscriber should be able to authenticate to the operator (using the mobile identity token) without specifying any service context and obtain a security token that only asserts the subscriber’s mobile identity, which can be used for any third-party service. The mobile network operator and especially the third-party service provider should be sure that only the subscriber can prove ownership of the security token. The security token should only be valid for a limited amount of time to ensure freshness of the mobile authentication. 

2. It may be required that the third-party service provider is not able to learn the real mobile identity of the subscriber (i.e., mobile phone number), but a registered pseudonym instead. The mobile operator’s authentication service may effectively act as a pseudonym service, issuing security tokens that assert a pseudonym. The operator is able to map the mobile identity to the appropriate pseudonym. (Authorised entities would also be able to ask the operator to map a pseudonym to a mobile identity.) Such a pseudonym service may also be provided by a third-party service provider. In order to obtain a pseudonym a specific registration interaction between the final service, the pseudonym service and the subscriber would be needed. 

Discussion / conclusion: Summary of requirements

This chapter analysed the generic privacy objectives related to billing/payment and authentication within mobile web services scenarios. Referring to the categorised survey on traditional and privacy-enhancing identity management mechanisms relevant to mobile identity management (see section 2.1), this chapter focused on the following specific privacy requirements: 

1. I.b. Pseudonyms (for authentication means) 

2. I.c. Credentials (in the form of payment authorisations) 

3. VI Interoperability and Gateways (Mobile Web Services standards) 

Note that while this chapter focused on the specific privacy requirements above – concentrating on the interactions between the entities – most other privacy requirements that are listed in the survey, would be relevant to overall Mobile Web Services solutions as well.