webinos – sensor based scenarios – managed service scenarios for sensor networks ..

 
Firstly, some goals of the webinos project adapted from the webinos introduction

The purpose of the Webinos project is to define and deliver an Open Source platform, which will enable web applications and services to be used and shared consistently and securely over a broad spectrum of connected devices.

In practice, this is more than the APIs on individual devices. So, within a web based scenario, the service should be able to potentially

-  Run across devices and domains

-  Share preferences, status and synchronized information across multiple devices

-  This applies to device features as well – ex to use smart phones as input devices

-  Allow consistent access to developers

-  Manage user authentication, cross device events, metrics and application distribution across devices

The tagline of the webinos project is “Secure Web Operating System Application Delivery Environment”, indicating that security (and also privacy)  is a significant part of the project.

Some of the functionality already exists in proprietary implementations – for example Sky go – which allows Sky subscribers to watch Sky TV on their designated iPhone and iPad devices. Webinos aims to do this and LOT more for the web across platforms by creating truly distributed applications.

In practice, this means for web based applications, webinos will allow for the following:

  • Applications which make optimal use of the resources on the featured devices of TV, Automotive, Tablet, PC and Mobile
  • Applications which interoperate over diverse device types
  • Applications which can make use of services on other devices owned by the same person
  • Applications which can make use of services on devices owned by other people
  • Discovery mechanisms to find services, devices and people, on multiple interconnect technologies – even when they are not connected to the internet
  • Efficient communication mechanisms, that can pass messages over different physical bearers, can navigate firewalls, and make sensible use of scarce network resources
  • Promiscuous communication mechanisms, that will find the best physical connection to pass messages over (not just IP)
  • Strongly authenticated, communication mechanisms that work bi directionally – we know we really are talking to the remote service, device we thought we were – tackling head on the spoofing and phishing weaknesses of the web
  • And finally, implementing distributed, user centric policy:
    • allowing the user to define what applications work on what devices,
    • to define what information is exposed to other services
    • and ensuring these capabilities are interoperable and transferable – ensuring a user stays in control of their devices and their applications

To implement functionality, webinos architecture introduces three components: the webinos web runtime, the webinos personal zone hub(PZH) and the webinos personal zone proxy(PZP)

A webinos web runtime, is a special type of browser which is capable rendering the latest Javascript, HTML4/5 and CSS specifications. It is responsible for rendering the UI elements of the webinos application. A webinos WRT must be able to access the webinos root object from Javascript. Via this root object the third party developer will be able to access the webinos functionality. A webinos WRT differs from a normal browser or web runtime in that all extended Javascript functions as well as some normal browser behaviours (such as XHR) must be mediated by the webinos policy enforcement layer. The webinos web runtime is tightly coupled to the PZP and presents environmental properties and critical events to the PZP.

 

 

In webinos, the Personal Zone is a conceptual construct, that is implemented on a distributed basis from a single Personal Zone Hub (PZH) and multiple Personal Zone Proxy (PZP)s

The webinos personal zone hub PZH provides a a fixed entity to which all requests and messages can be sent to and routed on – a personal postbox as it were. The PZH is also the authoritative master copy of a number of critical data elements that are to synced between Personal Zone Proxy (PZP)s and Personal Zone Hub (PZH) – for example certificates.

The PZH enables functionality like the creation of a User authentication service,  secure session creation for transport of messages and synchronisation between the PZP and PZH. The PZH also stores the policy files.

The webinos personal zone proxy PZP  acts in place of the Personal Zone hub, when there is no internet access to the central server. The PZP fulfils most, if not all of the above functions described above, when there is no PZH access. In addition to the PZH proxy function, the PZP is responsible for all discovery using local hardware based bearers (bluetooth, zigbee , NFC etc). Unlike the PZH, the PZH does not issue certificates and identities.

For optimisation reasons PZPs are capable of talking directly PZP-PZP, without routing messages through the PZH

Thus, a webinos application has the folowing characteristics:

-  A webinos application runs “on device” (where that device could also be internet addressable i.e. a server).

-  A webinos application is packaged, as per packaging specifications, and executes within the WRT.

-  A webinos application has its access to security sensitive capabilities, mediated by the active policy.

-  A webinos application can expose some or all of its capability as a webinos service

-  An application developer is granted access to webinos capabilities via the webinos root JavaScript object.

An application developer programs and packages the application according to the webinos specification. They use the API to gain access to functionality. While much of the distributed capabilities of webinos are transparent to the developer, the developer is able to access functionality like discovery and service binding.

So, how will this all work for sensor based devices(zero screen) especially in a smart cities ecosystem?

This is the problem I am trying to address:

Consider some use cases: In all cases, we are essentially considering a group of managed devices under some secure, distributed, private and managed data scenario (for example – the data is owned by the customer)

a)  Consider a standard bluetooth heart rate monitor which could be worn by a customer. In this case, the data is stored on the mobile device and accessed by the customer. However, a variant of this use case is – the data could be transmitted to the physician. This is no different than wearing the more expensive heart rate monitors which doctors normally prescribe – except that the data in this case could be transmitted to the doctor in close to real time. In this case, the PZP would be on the mobile device and the PZH would be on the server or with the doctor. In this case, we could even conceive of a ‘managed third party service’ which is specialised in handling data from multiple customers on their behalf and which the doctor can access. Such a managed service would need the security framework which webinos provides but would be far cheaper than existing medical alternatives since it is based on inexpensive devices which can be hooked together

 

 b)  A second scenario could be based on an open energy monitor based device such as emonbase. It is based on the idea that customers own their own data and consequently could use that data to either negotiate or switch energy providers. Once again, you could have many devices within the home each running a PZP connected to a PZH which runs on a PC or a home gateway. The above principles apply for distributed and secure data management and also for a secure, third party managed service independent of the specific energy provider (in which case, the PZH is managed by the third party).
These are exploratory ideas and I am still thinking about them – hence they will evolve. Comments and feedback welcome