The aim of BONDI is to seek ways of increasing impact in the area of device security and enabling applications in the mobile web and emerging web runtime environments. The ambitious goals of Bondi is to encourage every mobile web runtime to implement a common set of interfaces for accessing key device and network resident capabilities in a secure manner.
OMTP is collaborating with existing fora like W3C and Open Ajax Alliance (OAA) and also aims to create an open environment in which source code as well as object code (Reference Implementations) can be reviewed to inform and complement the specification work. This will assist the developer community and help ensure that the specifications result in real implementations.
By its very nature, the project is ambitious but also attracts some skepticism.
I have been involved in technically project managing the gap analysis phase leading up to this project on behalf of AMF ventures (supported by an excellent team comprising Al Briggs, Alex Kerr, Jean Marc Rocci, Dean Bubley, Paul Golding , C Enrique Ortiz and others).
Due to this background, I know a lot about this project – and also about the ethos leading up to this project. In addition, Identity and Reputation systems are related to my PhD work – and of interest to me in general. Hence I will cover Bondi and other related developments in a more detailed analysis probably spanning more than one blogs.
Many thanks to Dr Nick Allott , OMTP CTO for his help with this blog .
Hopefully, you will find my analysis useful – and applicable to your work. In any case, as the browser becomes and application platform, we will encounter these issues – and hence there is a lot to learn from Bondi.
Also I like the collaborative approach. The reference implementation may be open sourced and OMTP has joined the W3C – all of which makes Bondi interesting.
Finally, we should view Bondi in a larger context – for instance network level APIs access like the recently announced GSMA 3rd Party Access initiative
As an organization, OMTP has evolved over the years – and I see the Bondi announcement as yet another step in this evolution. The constant element in its evolution has been OMTP’s emphasis on security – and Bondi continues this trend. Specifically, it addresses the problem of making the browser into a full development platform. This is interesting since it covers a key gap in the industry and works with a set of problems which we are only now beginning to encounter.
Firstly, let me give my personal ethos with respect to Openness, Security and Identity
a) Openness means the ability for customers to communicate without commercial and technological barriers. However, that does not mean ‘not secure’ or free.
b) I see a world comprising of both open and closed handsets i.e. ranging from handsets which will be completely open(but maybe supported by an insurance policy) to completely closed(for example with remote monitoring etc)
c) As the browser evolves into a full development platform and devices become more like PCs, I believe that we are going to encounter some problems which we have not seen so far. In many cases, these will be Identity and security related.
d) Sometimes we may not take browser security seriously. However, it will take only one major incident / security breach to bring this issue to forefront. It is better to act proactively but pragmatically. This is the same line of thinking I take with my advisory role at the Joint research commission at the European Union i.e. as a general principle – as mobile devices become more PC like, we will see some of the same issues on the PC
The Bondi architecture is as shown above. A brief discussion about some of the components follows. It is a comprehensive approach covering many aspects pertaining to device APIs.
Policy framework : The security manager is the architectural entity responsible for securing access to device Application Programmers Interfaces (APIs) from web applications (e.g. web pages and widgets). Specifically it will embody and police a security policy encapsulating the rules concerning which web application can access which API under which circumstance.
Packaging formats and credentials: Web applications (web pages and widgets) must be able to provide an identity and associated security credential(s) that can be used to make security decisions about what the application can and can’t do. Web applications must also be able to describe their dependencies on APIs or device capabilities, in order that the application life-cycle can be effectively managed.
Policy management: In a number of cases, it is desirable to update the security policy on a device over the air: For example, when a new device API is installed (see below) or the “owner” of the security policy changes (e.g. the user changes Operators or delegates responsibility of part of the policy to a trusted third party) To address these use cases it is likely that a standardized policy management protocol will be needed. OMA DM or XML are potential protocols to implement these features.
Dynamic API: Installation interfaces - When a web browser based application runs or widget is installed it may require access to specific device APIs (e.g. send a message). This will require a set of APIs for discovery (does the specific API required already exist?) and installation (if they do not exist). The Dynamic API Installation interface allows the device capability APIs to be dynamically extended on request.
Dynamic API: Packaging format - APIs that expose device capability, where those native devices platforms are fragmented operating systems, will necessarily come in many different forms. Although the implementation of these APIs must differ (in order to reduce the web facing fragmentation), there is a strong argument for standardizing the packaging of these APIs to facilitate interoperability of provisioning and discovery.
Dynamic API: Discovery protocol – The logical extension of standardizing the packaging involves coming to a common view on the over the air protocols required for provisioning and discovery. These will provide the necessary interoperability with client resident applications and servers responsible for distributing the components.
Communications Log Interface : The communications log interface will include APIs to inspect the voice call and messaging logs that provide a history of recent phone behaviour.
Application Invocation Interface : Most APIs provided to a web application will be APIs that provide an abstract data link between web app and native device capability. In other words calling the API will not directly impact the phone user interface, user interface impact will instead be rendered by web elements. The functionality provided though the application invocation interface is different, in that calling the API will transfer UI control to a different host application. For example, through the application invocation interface it will be possible to set up a voice call through the native dialler application, which contrasts with the mechanism of setting up a call through the Telephony interface, under which circumstance the UI control will be retained by the web application directly.
Messaging Interface: The messaging interface provides function calls to send and inspect SMS, MMS and email messages.
Gallery Interface: The Gallery provides application access to media resident on the phone, including but not limited to, videos, pictures and music. Functions will be provided that allow both file level querying and investigation and presentation through a suitable media player
Persistent Data Interface : A set of file persistence function calls provides the compelling capability for a web application or widget to continue to usefully function, even if there is no internet connection, by essentially caching important data and code files.
Phone Status and Properties Interface: The behaviour of many applications can be usefully informed and optimized by querying essential phone status information. This is a potentially broad subject that will be delivered in phases, but could include useful information such as: battery level, network connection status, phone orientation, presence of camera or available memory.
Personal Information Interface: The PIM API covers access to full suite of personal information to be found on the device, including: contacts, calendar, task and notes. The API calls provided will support creation, deletion, edit and read capability.
Location Interface: Location information for the device can be provided through this interface. This interface shall support the provision of this information via a number of different implementation methods, including but not limited to: Cell ID, remote web interfaces, GPS, A-GPS, Bluetooth connected GPS devices.
User Interaction Interface : This collection of function calls will provide the capability for the application to interface with the user in manners not currently covered by web standards. This includes such things as, vibrate and tone notifications (integrated with phones sound settings), menu functions, to overload soft keys and menu functions, to allow widgets to render in controllable screen areas.
Application Settings Interface: The application settings functional group includes all APIs and facilities that relate to application settings and preferences, including (if supported): static parameters defined by the author of a web application; parameters configurable by the author or publisher of a web application to repurpose it to a specific device, locale, etc at design time, or at purchase/provisioning time; parameters read and/or modified programmatically by the application when it runs.
This is a comprehensive approach – and much will depend on how the industry takes up these initiatives. In any case, as the browser becomes and application platform, we will encounter these issues – and in that case, there is a lot to learn from Bondi.