From MemberWiki

Jump to: navigation, search


About this wiki page

In February 2009, OpenAjax Alliance will review and provide feedback to the OMTP on the BONDI 1.0 Release Candidate specifications. This is the main (table-of-contents) page for the BONDI review activities.

Call to Action (first deadline: Feb. 25, 2009)

OpenAjax Alliance will collect feedback from its members via its wiki. We are calling on members of OpenAjax Alliance to review the BONDI materials and supply feedback comments within one of the BONDI wiki pages, as follows

  • BONDI - This wiki page
  • BONDI Feedback APIs - Feedback page relative to the general approaches that OMTP is using for its APIs. Are the APIs understandable, familiar in approach, and convenient to JavaScript developers?
  • BONDI Feedback Security - Feedback page relative to the security features in BONDI. Is the design robust? Are there any security holes? Are the security features easy enough to use?
  • BONDI Feedback Enterprise - Enter any detailed spec errors on this wiki
  • BONDI Evangelism - Possible ways that OpenAjax Alliance might be able to help evangelize BONDI
  • BONDI V2 Wishlist - OMTP will start discussion about future versions of BONDI in March 2009. This wiki page collects any feature requests from OpenAjax members.
  • BONDI History - Quick introduction of historical activities leading up to BONDI initiative


BONDI 1.0's release candidate went out on Feb 9, 2009, and there is a 28-day public review period. The Mobile Task Force at OpenAjax Alliance will be collecting feedback, which will be made available to OMTP before the 28-day review period is over. Here are key dates:

  • Feb. 9, 2009 - BONDI 1.0 RC published
  • Feb. 12, 2009 - Mobile Minutes 2009-02-12
  • Feb. 12-25, 2009 - OpenAjax members enter feedback on the OpenAjax member wiki
  • Feb. 26, 2009 - Mobile TF phone call reviews feedback
  • Feb. 27 - March 9 - Organize feedback and send to OMTP

BONDI Introduction and Overview


(some of this has been copied from, which has a longer version)

During 2007 and 2008, it became increasingly apparent that the future direction and success of the mobile web could be harmed without a concerted effort to drive a standardized approach to how web applications access the key local capabilities on the mobile device. If web applications had to use different APIs (for the same capability) on different devices and platforms, then development of web applications which work on any mobile device would not happen. On top of this, the risk of malicious web applications having free access to local mobile capabilities is unacceptable. Therefore, a need to create some form of security layer to protect the user from harm was essential.

It is with this background that OMTP launched its BONDI project with the aim of acting as a catalyst to drive the standardization of a small set of key interfaces from web services to mobile devices and also to put in place a well understood and user controlled security policy with which to protect the user.

BONDI consists of several activities, each of which interacts and as a whole builds towards the aim defined above.

  • API specifications – A set of Doxygen generated HTML pages that define the syntax and semantics of the BONDI APIs
  • Security Policy specifications – An interoperable XML description of the security policy which defines the access that a particular web application and widget will have to the BONDI APIs.
  • Open source Reference Implementation (RI) – The RI is a real concrete example of how the interfaces and security specifications should be implemented. The RI SDK contains API documentation and example code.

BONDI specs

Widget samples

Widget Gallery

Overview of BONDI technologies

Widgets and Web pages

The APIs and security features found in BONDI apply to both installable mobile widgets and to Web pages running in a browser.

Regarding installable mobile widgets, BONDI provides APIs that allow the widget to access to selected Mobile Device APIs under the supervision of a security manager, which enforces the rules found in a policy file.

Regarding Web pages, BONDI provides APIs that enable a Web page to reach out of its same-domain sandbox and gain access to selected Mobile Device APIs under the supervision of a security manager, which enforces the rules found in a policy file.

Compatibility with W3C Widgets

For installable mobile widgets, BONDI embraces the W3C Widgets specifications, and has been working closely with the WebApps WG at the W3C on that initiative, including:

With W3C Widgets, an installable mobile widget consists of a ZIP file whose file extension is ".wgt". The ZIP might might contain a metadata file named config.xml and might contain digital signature information. The files that provide the user experience are also placed inside the ZIP. All of the BONDI examples

use Ajax (i.e., HTML+JavaScript) for the user experience; however, both W3C Widgets and OMTP BONDI are independent of the rendering technologies. For example, SVG Tiny widgets are another likely scenario, given how widely deployed SVG Tiny is on mobile devices.

The BONDI effort has defined small extensions to the W3C Widgets' configuration metadata file defined in Widgets 1.0: Packaging and Configuration, where it is possible to add a <bondi> element into the metadata file. As it stands now, the <bondi> element can only include:

  • Supplemental information about widgets that run in the background and/or are hidden (i.e., no visual presentation)
  • Supplemental information about a particular widget's requirements to access the network and take advantage of local storage

Several independent API modules

BONDI 1.0's APIs are organized as independent modules, each with a unique feature ID:

Feature name FeatureID Notes
Application Configuration  ?
Application Launcher For example, launch the mapping application. (I'm pretty sure the old application is replaced by the launched application.)
Camera  ?
Commlog  ?
File system  ?
Gallery  ?
Geolocation APIs having to do the using the GPS to gather current location. This API is tracking W3C's geolocation API standards effort.
Messaging APIs for email, SMS and MMS
Device status  ?
Calendar  ?
Contacts  ?
Tasks  ?
Menus  ? APIs to post menus. For old-style phones (i.e., pre-touchscreen), the menus would be available via the two menu keys found on many cell phones just above the keypad.

Loading of APIs

Access by a Web Application to any given API is not automatic but must be requested. In BONDI terminology, a Web Application makes a request for one or more Features, each expressed as a URI.

The space of Features available is common to both Widgets and Websites, although the method used to request access is different.

A Widget expresses a dependency on a Feature by making a static declaration in the Widget Configuration Document, via the <feature> element. This element is defined by the W3C Widgets packaging and Configuration specification but it is given special meaning in the context of BONDI Widgets.

Websites express their dependency on Features programmatically, using a JavaScript API defined by BONDI, ie


Loader implementation in current Reference Implementation

In the current BONDI Reference Implementation, widget <feature> declarations are processed at installation time, and a <script> is dynamically inserted into the HTML of the widget to gain access to the requested functionality via a plugin. the Widget author is not required to include anything in the HTML. (This install-time script insertion is temporary and is expected to disappear in later revisions of the RI.)

For Websites, access to the bondi.requestFeature() access to this API is dependent on explicitly including a loader script. This mirrors the practice of, for example, Gears and BrowserPlus. However, a browser that had BONDI support built-in would be expected to have the bondi.requestFeature() API available directly.


BONDI includes specifications for defining access control policies, indicating what BONDI APIs can be used by a particular application. The access control definitions are written in an XML grammar defined by the BONDI project. This XML grammar adopts the security model defined in the XACML specification (from OASIS) and provides similar markup.

By default, widgets and Web sites cannot access the BONDI APIs. The policy file opens up selected APIs to a particular widget or Web site. The policy grammar might say something like "Application Foo, with a digital signature that matches the following hash code, can access the geolocation APIs." In general, the smallest amount of access that a particular application might need is granted. For example, File system access typically is given only to a section of the local hard disk that is specific to that application, and Network access typically is given only to a particular Web site.

The main difference with the BONDI grammar is that it is greatly simplified versus XACML, particular its use of a single XML namespace (versus XACML, which uses multiple XML namespaces). Beyond minimization of namespaces, the BONDI policy markup is more simple and straightforward in how policies are defined, with the goal that these files could be created by hand by people who were not world-class security and XML experts. The BONDI policy markup language cannot be directly transcoded into XACML, but if XACML adds a few minor extensions, then in the future such an automatic conversion process would be possible.

Two things that are not clear about BONDI security features has to do with how these features will be used in the real world:

  • Who will author the policy files in various circumstances. In some cases, clearly the mobile cell network operator will author policy files, particularly with regard to widgets and Web sites that the operator has developed. In other cases, will the policies be defined by the operator, the device manufacturer, the browser vendor, the user's employer, or the user?
  • What will be the user experience for any situations where the user has to explicitly allow a particular widget or Web page to be allowed to access a particular API?

It is expected that, over time, the industry will learn from experience and gravitate towards a set of common best practices.

Personal tools