Webinos - a reminder of key functionality¶

This section defines the roles and responsibilities of the key architectural components in webinos and at a high level defines the logical flow, and process during normal webinos interactions.

Webinos builds upon the state of the art for web applications. Taking HTML5 and W3C DAP technologies as a foundation, it extends these concepts to 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

The Webinos specification¶

The formal specification is broken into subject areas, each of which has its own section

• Core architecture and specification: defines the key architectural components and processes that dictate how the webinos technology works together
  • Foundations: by reference to the critical foundation technologies, such as core widget packaging specifications, defines and extends the data formats and protocols required to write and package applications, that interact with webinos.
  • Authentication: defines the protocols required to authenticate the critical webinos components against each other
  • Discovery: covers the mechanism by which different services can be found over multiple different networks.
  • Messaging: webinos defines its own mechanism for efficiently pasting different message types over the webinos overlay network
  • Context: defines privileged mechanisms by which the contextual information and events from multiple devices can be aggregated and supplied and later disseminated from the Personal Zone Hub
  • Security: outlines the critical security elements, which are explored in greater detail in the Security Architecture definition
• APIs: formally defines the Javascript APIs which a local application may discover and use on device, and which may be invoked remotely from an application on another device
• Security: formally specifies the APIs, data formats and protocols required to implement a secure distributed web application execution environment

The webinos key architectural components¶

webinos Web Runtime (WRT)¶

A webinos web runtime, is a special type of browser. It should be 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.

A webinos WRT will present environmental properties and critical events to the Personal Zone Proxy (PZP) so that it may process the security policy and contextual events, correctly.

A webinos WRT should be deemed tightly bound to the Personal Zone Proxy (PZP).

There is special case of WRT that binds to the PZH not the PZP, hence server vs device centric. This variant is called a Server Based Runtime (SRT), rather than a WRT.

Specification areas¶

The web runtime component must implement the following aspects of the specification

• Foundations:
  • Rendering and code: the WRT must be compliant with all the HTML5, CSS, Javascript versions defined in the foundations document
  • Packaging: the WRT may be responsible for unpacking the application manifests (W3C widget specification). However, in the implementation phase we may also evaluate the advantages of performing the processing of this at the Personal Zone Proxy (PZP) instead
• Security:
  • PIP: the WRT must act as a policy information point for the webinos policy. In other words the WRT must provide "security context" and call backs into the PEP (Policy enforcement Point) which resides within the Personal Zone Proxy (PZP).
• APIs: the WRT MUST provide the webinos object at document level upon which all the webinos objects and methods may hang. In the implementation phase we shall evaluate the pros and cons of implementing the APIs within the WRT natively vs

webinos Personal Zone Hub (PZH)¶

The Personal Zone has already been introduced in the Overlay Networking Section.

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 critical functions that a Personal Zone hub provides are:

• An fixed entity to which all requests and messages can be sent to and routed on - a personal postbox as it were
• A fixed entity on the web through which requests and messages can be issued, for security and optimisation reasons.
• An authoritative master copy of a number or critical data elements that are to synced between Personal Zone Proxy (PZP)s and Personal Zone Hub (PZH), specifically
  • Certificates for Personal Zone Hub (PZH), Personal Zone Hub (PZH) mutual authentication
  • Hashes for user authentication
  • Certificates to authenticate PZXs of trusted people against each other
  • Application identifiers (and/or certificates) of applications granted access into the zone
  • Service identifies (and/or certificates) for trusted services to which the personal zone may attach
  • (Subject to investigation) device identifiers, to assist with platform integrity tests
  • (Subject to investigation) credentials for "non webinos" services to give a pseudo single sign on experience
  • All policy rules, for distributed policy enforcement
  • All relevant context data
• The functions therefore that a Personal Zone Hub (PZH) can support are
  • User authentication service
  • Personal Zone Proxy (PZP) secure session creation for transport of messages and synchronisation
  • Service session creation for secure transport of messages between applications and services
  • Secure social networking: using the exchanged certificates between trusted people
  • Potentially: single sign on service to other web services, using the Personal Zone Hub (PZH) as a secure proxy
• A webinos service host: a Personal Zone Hub (PZH) can host directly Services/APIs that other applications can make use of.
• Context sync: the Personal Zone Hub (PZH) should act as the master repository for all context data
• A webinos executable host: a Personal Zone Hub (PZH) will be able to run a server resident webinos applications (these will be JavaScript program files wrapped in a webinos application package)

Specification areas¶

The Personal Zone Hub (PZH) component must implement the following aspects of the specification

• Foundations:
  • Rendering and code: the Personal Zone Hub (PZH) will run server resident webinos applications using node.js or similar
  • Packaging: the Personal Zone Hub (PZH) should be capable of unpacking and performing security checks on packed widgets
• Security:
  • The Personal Zone Hub (PZH) must store the policy files
  • The Personal Zone Hub (PZH) should act as a server based Policy enforcement point- therefore must mediate all relevant traffic
• Messaging: the Personal Zone Hub (PZH) must be able to route messages to the relevant Personal Zone Hub (PZH) or Personal Zone Proxy (PZP), or in cases where the message is routed to a locally hosted service, pass it for execution
• Synchronisation: the Personal Zone Hub (PZH) must implement the synchronisation algorithm and process synchronisation protocol messages.
• Authentication:
  • the Personal Zone Hub (PZH) must allow for a user to authenticate, or raise their authentication level.
  • the Personal Zone Hub (PZH) must authenticate Personal Zone Proxy (PZP)s and other users to set up trusted sessions

webinos Personal Zone Proxy (PZP)¶

The webinos Personal zone satellite proxy, acts in place of the Personal Zone hub, when there is no internet access to the central server.

In order to act in its place, certain information needs to be synchronised between the satellites and the central hub.

This information has already been listed above.

The Personal Zone Proxy (PZP) fulfils most, if not all of the above functions described above, when there is not Personal Zone Hub (PZH) access

In addition to the Personal Zone Hub (PZH) proxy function, the Personal Zone Proxy (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

Specification areas¶

The Personal Zone Proxy (PZP) implements all of the above functions, with the following differences

• Messaging:
  • A Personal Zone Proxy (PZP) routes all "internet" messages to the parent Personal Zone Hub (PZH) for distribution
  • A Personal Zone Proxy (PZP) routes all "local" messages to the relevant local device, using
• Discovery: the Personal Zone Proxy (PZP) must implement a full array of local device discovery protocols.
• Security:
  • the Personal Zone Proxy (PZP) is THE primary policy enforcement point for all application processing
  • the Personal Zone Proxy (PZP) will attest to the integrity of other key components on the device
• Packaging: a Personal Zone Proxy (PZP) may optionally - subject to investigation - perform webinos application package processing and integrity checking on behalf of the WRT

webinos Application¶

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.

Specification areas¶

An application developer needs to be aware of the following parts of the specification

• Foundations: an application needs to packaged and programmed according the foundation specification
• APIs: a developer has access to the rich set of capabilities defined within the API specification
  • infrastructure capability: much of the intelligence of webinos is provided transparently to users. However certain key functions, such as discovery, and service binding, are provided

webinos Service¶

A webinos service is a collection of functions and events, that are accessible by an webinos application

These functions and events are always presented to the application developer as a sets of JavaScript functions, no matter where the implementation resides.

There exist the following sub-types of webinos services

1. native device webinos APIs: such as specified in WP3.1. These may be implemented on the same device on which the application resides, and the implementation may be provided through a Javascript binding to native code, via plugin technologies such as NPAPI, or indeed hard-coded enhancements to a JavaScript engine. Access to the API must still be mediated by the PEP (policy enforcement point) within the Personal Zone Proxy (PZP)
2. remotable smart-device hosted webinos APIs: APIs that can be accessed remotely (using JSON RPC). A remotable webinos API is hosted by a Personal Zone Proxy (PZP) and again access is mediated by the PEP on the Personal Zone Proxy (PZP) of caller AND the Personal Zone Proxy (PZP) of provider
3. remotable dumb-device hosted webinos APIs: As above, where the device is not a smartphone, PC or tablet, but a small sensor-like device which has its own Personal Zone Proxy (PZP) and therefore can directly authenticate to the PZ and communicate via JSON RPC
4. remotable super-dumb-device: as above but device is even more lightweight - and cannot talk webinos directly. Instead a host device presents as webinos driver (a mini Personal Zone Proxy (PZP)) that can communicate natively to the super-dumb-device and transcode the bi-directional comms into webinos protocols.
5. remotable server hosted APIs: these are web services, accessible javascript (using JSON RPC). These are hosted by a Personal Zone Hub (PZH) and security mediated by the PEP within the Personal Zone Hub (PZH)
6. application hosted APIs: a full application, which is hosted by the WRT may present external services (Javascript APIs) that other applications can then make user of

Specification areas¶

An webinos service must take note of the following parts of the webinos specifications

• Discovery: a service must be discoverable and be able to describe itself to the application in accordance with the discovery specification
• Messaging : a service must be able to receive and respond to incoming RPC messages

Local Connections¶

One of the critical innovations of webinos, is the virtual overlay network that allows different applications and services to talk to each other over many different interconnect technologies.

Not only are the interconnect technologies for local messaging, there are three different scenarios in which this communication can take place

These are highlighted in the diagram below.

In turn:

1. Connecting to a full smart device, that hosts both a PZP (therefore can host native APIs presented as services) and a WRT (so can host webinos applications exposing webinos services)
2. Connecting to a dumb device, it hosts a PZP but not a WRT. This means that it can expose only native APIs, not webinos applications
3. Connecting to a super-dumb device, it hosts neither a PZP nor a WRT, but can expose webinos services - if the client PZP hosts a customised driver

Specification areas¶

The personification that outline the detail of these connection scenarios are to be found in

• Overlay networking
• Discovery
• Messaging