SDP Global Summit 2013
1 like313 views
This document discusses mobile operator APIs and their evolution. It provides the following key points: 1) Operator APIs have evolved from traditional server-to-server integrations to support independent smartphone apps through APIs exposed to developers. 2) Operators now need to consider what APIs would be useful for smartphone apps, such as mobile identity, payments, and customer self-care APIs. 3) Effective technical solutions for operator APIs include using REST/JSON protocols over SSL, strong authentication methods, and security measures to protect against attacks and unauthorized access.
SDP Global Summit 2013
- 1. Mobile Operator APIs Enablement, Exposure and Creation – Delivering Useful Services SDP Global Summit 2013 19. 9. 2013 Rome Martin Prosek, VAS Platform Development Manager Telefónica Czech Republic
- 2. Telefó About Telefónica Czech Republic Fixed and mobile voice and data, IPTV Operated under commercial brand O2 1
- 3. Introduction 01 API Evolution Quick Review 02 Operator‘s API Offer 03 Effective Use 04 Technical Solutions 05 Real Life 06 Recommendation Disclaimer: The opinions of the author expressed in this document do not necessarily state or reflect those of Telefónica company 2
- 4. Evolution Traditionally the SDP served for Operator/Developer relations In principle server to server integration Generally B2B collaboration model Operator‘s Network Operator‘s Network Developer‘s Developer‘s Application Application
- 5. Evolution Open APIs allowed moving of part of the value chain out side of the operator Short-tail partners, biggest players… Also 3rd party applications, not only operator branded Still server to server integration Standardization took place… Mobile payments in CZ Operator‘s Network Operator‘s Network Developer‘s Developer‘s Application Application
- 6. Evolution Smartphones allowed to have independent apps on the device Smartphone apps act as thick-weight clients (native applications)* thickDevelopers benefit from many APIs (internal in OS or external…) Use client-server integration clientParallel with the operator world, different APIs Collaboration model closer to B2C *Light-weight apps (widgets, HTML5…) are not so successful as the native yet Operator‘s Network Operator‘s Network Smartphone Smartphone Application Application
- 7. Evolution Smartphones created separated ecosystems With their own APIs Operator becomes a dumb pipe Smartphone Smartphone Application Application Smartphone Smartphone Application Application
- 8. APIs for Smartphone Apps Amount apps is still growing Need of APIs is growing as well!
- 9. APIs for Smartphone Apps But the need of operators APIs like SMS, MMS, Calling, Location not – smartphones have them already in the OS! Or even OTT competitors can do it better… What else could operator offer to developers?
- 10. Operator APIs Useful for Apps Mobile Identity User Profile Payments (in-app) Content services (if offered by operator…) Unified communications (if offered by operator…) Customer Mobile Self-care …
- 11. APIs… Why Should Developers Use Operators APIs… Developers do not care about operators If asking for something, not for APIs, rather for exceptions from FUP or free data access to their services What can motivate them to use operators APIs? • • • • • Financial incentives from operator Need of touch with local market (might be also regulatory condition…) Access to user identity and profile Access to payments … or example … TU | Go
- 12. Operator APIs – Effective Use Better to ask what operator does need? Operator needs own apps to keep the presence on device device!
- 13. SelfCustomer Mobile Self-care APIs The APIs enable • • • • Service settings reading, changing Service ordering Service management (e.g. voicemail…) Loyalty programme Ideal candidate to keep presence on the smartphone APIs can be used directly by the app Mobile identity can be utilized to speed the sign-in
- 14. Technical Solution Different from traditional server-to-server APIs Direct access to operator‘s API Open from Internet Very specific for each operator No well established standards for exposal of these APIs yet App App App App Internet App App Operator Operator
- 15. Technical Solution – Protocols Use of SSL is common REST call examples GET /UserProfile/v01/HomeLocation/420602749374 HTTP/1.1 REST and JSON are dominant* POST /Payment/UNICA/REST/v2/reservedPayments HTTP/1.1 JSON example { "userId": "acr:23002abcd420602123456", "description": "Birds Space Premium In-app Payment", "Amount": 46.42, "totalAmount": 56.63, "taxAmount": "10.21", "currency": "CZK", "referenceCode": "ref1234ABCD", "merchantId": "1234567" "channel": "D2B", "productId": "123456789012345", "productClass": "DigitalGood", "itemId": "https://play.google.com/store/apps/details?id=com.auvio.birdsspace.premium", "orderId": "7392947363", "merchantInfo": „Auvio Ltd., support@rovio.com", "revenueSharePercent": 5.00, "timestamp": "2013-04-05T14:30:12.043Z" } } *Even simpler APIs can be used (HTTP GET and Content-type text/plain…)
- 16. Technical Solution – Mandatory Functions SSL encryption Enhanced authentication (user, app, OTP support…) Intrusion detection High performance (1000 TPS and more) Light-weight processing Throttling Flexibility (API development time in hours) Governance
- 17. Technical Solution – Authentication The authentication model is extended Authenticate app (developer) • by some pre-shared key embedded in the app (API parameter, User Agent string, client SSL certificate etc.) Authenticate user (identity) • • NW based authentication (MSISDN) For WiFi accesses › Username/password authentication › One-time Password over SMS › Client SSL certificate › Even federated login (e.g. using Facebook account)
- 18. Technical Solution – Security Risks It is free internet – not operator‘s network! DDoS attacks to the API are possible Attempts to hack the API must be expected Anyone can reverse engineer the app and fake the credentials – identity theft Even worse case – trojan horse apps Embed security checks into the app Monitor app usage Use proven web technologies – WAF, IDS, SIEM…
- 19. Technical Solution – Authorization by User When opening any API for public use amongst app developers new issue would appear Application can do almost anything on the back-ground without informing the user Operators should not forget that they are responsible for everything that might be done to the customer Operators have right to authorize every request from the partner or the application Well suited is oAuth
- 20. Technical Solution – TEF CZ Framework Svr-side Apps Smartph. Apps Access Security Browsing GW API GW Orchestrati on Lego-like approach Enablers NW ESB IT ESB
- 21. Developer‘ Real Life – Disobedient Developer‘s… Even when the applications are made exclusively for the operator the developers tend to use connection to their own backend App App API B-E API B-E They are reasoning that their approach is better: • • • • • Cheaper development Better performance Shielding against API changes Guaraned operation … Operator has to find good counter-arguments… Operator Operator
- 22. Advantages and Opportunities For operators • User SDP for proven success case • Open the APIs for free use by developers For standardization bodies • Propose standard For vendors • Offer ready-made solutions, even including SDKs 21
- 23. Thank you.