GSMA: Help us, OneAPI proxy, you're our only hope

Continuing the fight against OTT players, mobile operators' group the GSMA has launched the OneAPI Exchange, a moderated proxy providing access to OneAPI functions across operators that are too lazy and uninterested to implement the standard properly.

The OneAPI, for those who've forgotten, is an API allowing applications to securely identify users and trigger billing events, and it is supposed to work across network operators without the need for a proxy or moderation - and the launch of both should tell you just how well that's going.

With operators determined not to follow the GMSA's lead in implementing the API itself they'll need the proxy run by Apigee on behalf of the GSMA, which is painting the best face on the solution like a smile on a dying clown.

OneAPI allows any application to create billable events that function across network operators. So users could download a game from one operator, then change contracts and, within the game, buy an additional level with the cost appearing on the new bill from their new operator.

With the OneAPI Exchange operators will have "the choice of providing developers with either their own customised applications programming interfaces, or standardised APIs" apparently. The GSMA assures us that this is a good thing which "leads to better flexibility for operators to participate in the OneAPI Exchange programme, according to their own business objectives". This would all be fine if those objectives didn't include annihilation of all the other operators...

There's nothing technically wrong with the OneAPI Exchange. The idea is that a developer writes an app using one operator's (proprietary) API to trigger billing, get an identity or perform some similar function. As long as the user of that app is on the same operator, then the Exchange is redundant, but when someone from another operator downloads the app, the API calls are then intercepted and redirected to the operator to whom those API calls make sense. The 'Exchange then mediates, providing a connection from the developer's operator to the user's, and the user remains unaware that anything so clever is happening.

It only works if the operators are all signed up to the OneAPI Exchange, which is less effort than implementing the OneAPI itself but will still take some commitment on their part. AT&T, Deutsche Telekom, Orange, Telefónica and Vodafone are all on board from the outset but almost all of those climbed aboard the OneAPI bus some time ago so continuing support is hardly surprising, and standards like this need wide adoption to become anything more than a footnote in the history of mobile app development.

A developer who wants access to billing and other functionality needs to decide whether they will use an API from Google or Apple, which will work across all the network operators seamlessly, or use an operator API which (thanks to the OneAPI Exchange) will now work across some.

An operator API might provide access to functionality beyond the reach of over-the-top players, such as pre-paid credit or call control, and might work in countries where Apple and/or Google haven't set up shop, but for the key functionality of billing and identity management, there seems little reason to select the operator option.

Right now the OneAPI is "currently in a working proof of concept form" despite the operator support, but there's plenty more information from the GSMA (PDF, six pages but with big pictures) for those still willing to bet on operator's retaining ownership of their customers. ®