Home
API Reference

Bango User Id

Bango® User ID and Identity Shield
User Identity and MSISDN policy
February 2007 (Updated May 2015)
Introduction
This document explains why MSISDN is inappropriate as an identifying key for billing mobile users and explains the BangoUserID solution whih is part of the Identity Shield system in the Bango Platform which has been deployed worldwide since 2003.
It covers the rationale and includes information on customer service, marketing, privacy, security and other factors this imposes.
Background
The Bango Payment Platform provides major App Stores and digital merchants such as Amazon, Google, Samsung, Blackberry and Microsoft with rapid and straightforward access to more than 100 different mobile operator (carrier) billing systems and a range of other non-carrier billing systems through a single coherent API.
Direct Carrier Billing (DCB) systems and the corresponding user experiences are NOT standard. They are specific to the mobile operator (MNO) of the individual consumer - which means that within a specific country there are likely to be several possible user experiences - each of which is controlled by the mobile operator in question, and in many cases there is a requirement for the mobile operator to be directly engaged in either or both of the authentication or consent to pay steps.
There are three steps involved in Direct Carrier Billing:

  1. Identify (including determining which operator, which user, and which DCB methods are available) 2. Charge (including pre-authorization, regulatory spend limits and potential age verification) 3. Customer care (including user queries, itemized billing, refunds and blocking requests)
    A "user identity" is the necessary common element linking these three steps and is therefore vitally important as a foundation for enabling DCB. The "user identity" system needs to connect together Platform(Bango), Mobile Operator, App Store and End User (both device and potentially the human with the device).
    Traditional Mobile Identity - the Phone Number
    The traditional solution to carrier billing has been to leverage the device phone number as the common identity.
    Voice and SMS services have always used “telephony” style addressing. A service is accessed by calling or sending a message to a “phone number”. For example “call 2222 for traffic” or “text SUBSCRIBE NEWS to 81010” or call 900-567-4321 for TAROT.
    The service at the other end can use “calling line identity” (CLI) to identify the end user, in the form of an MSISDN. This enables the service to send messages back or to identify the user to provide better customer service and also the operator can put charges on the user's bill.
    Many newer internet services and apps have used phone number as the identifying key - for example WhatsApp, Voxer, Viber etc.
    The m-Pesa mobile payment system and the recent UK paym.co.uk paymnet system use phone number
    Potential for MSISDN misuse
    The use of a phone number is fundamentally unrestricted. Because there is no central "switching point" for phone numbers, it is not possible to develop “spam prevention” services for inbound text or phone messages. Phone numbers can be used to send messages and make voice calls by anybody anywhere. A "whitelist" of valid MSISDN users is not possible.

© 2014 Bango plc
If an MSISDN starts being misused, it is possible for the number to be disconnected, but since the number is generally exposed to the consumer and may have been widely shared with unknown parties there is a high degree of resistance to changing phone numbers.
Furthermore, some countries have regulations (however impractical or unimplemented) that do not allow phone numbers to "leave the country". That would prevent them being used as an identity by parties outside the country.
DCB Identity Models
In an internet connected world, the “traditional telephony model” with MSISDN does not work.
A user’s mobile device is connected to the internet using web protocols over a wide range of bearers. There is no standard mechanism for passing a subscribers phone number to the web sites they visit. Most users and most mobile operators explicitly DO NOT WANT their phone number passed to arbitrary web sites.
Technically, when a user connects their mobile device to the internet through a mobile operator, the mobile operator does know the subscriber identity – so they can bill them for example. However, the majority of operators do not expose this information. This is the same as a fixed internet ISP guarding the phone number of their customers or the PC browser not revealing the email address of the user when they visit web sites.
Mobile operators within the same country often have widely differing policies. The same operator may have different policies across different countries. They may have different policies across different groups of subscribers in the same country, based on pre or post-pay model or in some cases different policies for the same user depending on the phone settings or the bearer used for access.
Increasingly, mobile devices are being used to access services though Wifi or “dual SIM” modes so there is more complexity to come.
Table A (below) lists some of the different identity models that are in use. The mobile web identity is needed by mobile operators to perform Direct Carrier Billing
Bango Identity Shield and Bango UserID
The Bango platform maps the operator user identity to a single coherent identity model.
When a user identity (or device identity) is required for subsequent DCB activity, the relevant operator specific identity, any credentials issued and any additional user information are stored in a robust and secure Bango hosted data store, and a key to index that information is generated by Bango in the form of an integer (typically with around 8-9 digits) from a sparse data space. This is called a Bango UserID.
Any operation requiring access to the user or information about that user must be accompanied by the Bango UserID - wich can then - subject to controls - make use of that information.
The Bango UserID can be "unlinked" from the database - preventing it from being used.
If information changes related to the user - for example an MNO "rolls" an identity code or changes some user specific parameters, the information can be changed without having to re-issue the Bango UserID.
Information can be provided to Bango that the MNO does not want to be passed to the App Store. Bango can pass a Bango UserID cross border, since it is not Personally Identifiable Information (PII) All the functionality accessible on a user through the Bango UserID is only provided to parties who have agreed
contracted terms with the DCB provider AND Bango - and only through secure methods, so there is no value in the Bango UserID itself.
Sensitive information need not be stored or transmitted through the App Store systems since only the Bango UserID need be used.
The App Store identity can be provided to Bango for association at Bango with the Bango UserID.

© 2014 Bango plc
Functionality enabled by Bango UserID
There are a range of operations that can be performed using the Bango Platform by a App Store making requests through the Bango API.
The requests are transmitted to Bango through a secure, signed link and require authentication of the App Store. Operations include:
Query payment methods available Start a payment (with contracted DCB routes) Commit a payment Cancel a payment Refund a payment Query a payment (restricted to that app store) Check status of user
All operations are validated against an agreement matrix which contains the business logic agreed between the App Store and the Mobile Operator providing DCB.
The Bango UserID functions in the same way as a classic "token"
Protection against misuse
Apart from the contractual protection, the Bango Platform is able to verify compliance with MNO policies by using a number of approaches including:

  1. Process compliance. Prior to accepting operations on a Bango UserID requested by an App Store, Bango can verify that specified previous operations have been performed. For example that a user has been authenticated by
    the biller or that the user has completed certain operations
  2. Activity constraints. Activity on a Bango UserID is subject to constraints imposed by the MNO for their DCB systems, which are implemented by Bango - for example spending envelopes.
  3. ID separation. A user can be given a separate Bango UserID at the point of identification which is associated with the set of credentials used at that point. Although at a later stage some technique like MSISDN equivalency might be used to determine that the users are the same, the individual App Stores need not know that.
  4. Activity coherence. Information about each request can be compared with historic user information to ensure that no unexpected or suspicious patterns materialize. (Bango Risk Assessment System - BRASS)
  5. Operator control. An Operator can supply Bango with information on users - for example churning of numbers, parental worries or thefy of device - so Bango can decouple the information from the Bango UserID and prohibit future use.
    Bango only provides its API to (currently seven) App Stores. These are the only people authorized to perform operations on the users and these are restricted to their data and the scope of their DCB relationships.
    The shielding of MNO credentials for the App Stores reduces risk for the App Store.
    Additional notes on privacy and security
    All information provided to Bango is tagged with a supplier reference and the Bango UserID to whom it refers. Access to any information through the Bango API, linked to a Bango UserID is restricted to those people who have been permitted access by the

© 2014 Bango plc
The Bango UserID cannot prevent a mobile operator (MNO) linking identities across multiple app stores or merchants or with other people they interact with. The MNO can already tie all that together from their own internal billing ID. It is therefore important that the contract between the App Store and the MNO clarifies what use will be made by the MNO of information they gather from processing payment transactions - in the same way that agreements with Visa or Mastercard limit the use of information sharing.
Information on the products sold or the classification of those products can be provided to Bango for use in billing narrative, for analytics or for user support. That information, if provided is only linked with a Bango UserID and will not be disclosed unless the supplier of the information permits that.
Since the Bango UserID is linked to an identity authenticated by a range of methods determined by the MNO or billing partner, there is no danger of a "phishing" style attack.
Tokenization
The Bango UserID is a tokenization system.
The sensitive data element - an MNO billing identifier - is replaced with a Bango UserID a non-sensitive equivalent that has no extrinsic or exploitable meaning or value. The Bango UserID is a reference (i.e. identifier) that maps back to the sensitive data through the Bango system. The mapping from original data to a token uses methods which render tokens infeasible to reverse in the absence of the Bango system.
The Bango tokenization system is secured and validated using security best practices applicable to sensitive data protection, secure storage, audit, authentication and authorization. These have been audited by teams from two of our major customers. The Bango system provides authenticated App Store applications with the authority and interfaces to request tokens, or to detokenize under strict rules defined by the DCB providers back to sensitive data.
The security and risk reduction benefits of Bango tokenization are substantial because the Bango system is logically isolated and segmented from MNO processing systems and applications that previously had to expose sensitive data to App Stores. Only the Bango system can tokenize data to create tokens, or detokenize back to use the sensitive data under strict security controls. There is no feasible means through direct attack, cryptanalysis, side channel analysis, token mapping table exposure or brute force techniques to Bango UserID back to MNO billing credentials or identity.
The result is minimized exposure of sensitive data to App Stores, people and processes, reducing risk of compromise or accidental exposure and unauthorized access to sensitive data. App Store applications can operate using Bango UserID instead of sensitive data.
The PCI Council defines tokenization as "a process by which the primary account number (PAN) is replaced with a surrogate value called a token. De-tokenization is the reverse process of redeeming a token for its associated PAN value. The security of an individual token relies predominantly on the infeasibility of determining the original PAN knowing only the surrogate value". Bango UserID meets this requirement.

© 2014 Bango plc
Providing support for customer service
When a customer calls an App Store for customer service, the only information known to the user (typically) is their own phone number and possibly the content bought, the time of day, and the model of their phone.
In situations where the phone number is available to an App Store, Bango can provide this to the App Store, customer support is straightforward. If Bango has the number but can’t reveal it to the App Store directly, the tracking of queries is also straightforward. Bango provides in interface where an App Store enters the customer phone number and Bango provides a list of transactions with the App Store, and if there are some, the Bango identity.
In situations where the phone number is not known to Bango or the App Store, identification of the transaction is more complex, using time of day or content type. In any case, Bango can initiate an identity process to determine the Bango UserID if appropriate.
MNO Policy Change
Mobile operators change their policies over time. When operators change policy, the Bango data store is updated accordingly and user information can be flagged to cause re-authentication whenever the Bango UserID is used. Alternatively the Bango UserID can be invalidated.

© 2014 Bango plc
Table A: Selection of Identity Models used in DCB
Model
Usage
OPEN USER-CODE: The mobile operator generates a unique (to them) identity for each subscriber, but does not reveal the phone number.
This is becoming most common
The operator is happy to provide a unique subscriber number that has no relationship with the subscribers phone number, but which can be used for persistent user identity.
example: KDDI
ROLLING USER-CODE: The mobile operator reveals a unique subscriber code, which is not the MSISDN to trusted, contracted third parties and the code has limited longevity - between 5 mins and many weeks.
This enforces user re-authentication on a common schedule based on MNO requirements..
Example: Some Telefonica
RESTRICTED USER-CODE: The mobile operator reveals a fixed unique subscriber code, which is not the MSISDN to trusted, contracted third parties but they are not permitted to pass on the code.
Like a phone number but they can rotate the number if they want to require all users re-authenticate.
Example: T-Mobile Germany 2002-2014
PARTNER MSISDN: The mobile operator issues the MSISDN to trusted, contracted third parties but they are not permitted to pass on the phone number to any third party.
Typically used by operators that are opening up off-portal, and that want to help outsource customer service load to off-portal providers. MSISDN helps customer service facilities.
Example: AT&T
RESTRICTED MSISDN: The mobile operator reveals the MSISDN to trusted, contracted third parties but they are not permitted to pass on the phone number, except under a set of explicit rules to protect the end user’s privacy.
The mobile operator permits third parties to obtain the user phone number, but it is only available under contracted terms involving security and usage restrictions.
This also enables the phone number to be “withdrawn” if a user decides to become anonymous again.
Example: Vodafone m-Pay model
PASSABLE MSISDN: The mobile operator reveals the phone number to trusted, contracted third parties but they are not permitted to pass on the phone number, except under a set of explicit rules to protect the end user’s privacy.
The mobile operator permits third parties to obtain the user phone number, and use it for almost any legitimate purpose, but only if the user is aware that their phone number has been revealed.
example: UK Payforit system