The “Internet of Things”: sounds exciting doesn’t it?

And if VC activity, funding grant opportunities and analysts reports are anything to go by, you would not be alone in thinking that this could be the “next big thing”.

But what exactly is it? Wikipedia gives us

The Internet of Things is a collection of technologies that make it possible to connect things like sensors and actuators to the Internet, thereby allowing the physical world to be accessed through software

Technopodia gives us

The Internet of Things (IoT) is a computing concept that describes a future where everyday physical objects will be connected to the Internet and will be able to identify themselves to other devices. The term is closely identified with RFID as the method of communication, although it could also include other sensor technologies, other wireless technologies, QR codes, etc.

But being a long standing subscriber to the Humpty Dumpty theory of semantics I will simply ignore all those and state for practical purposes I take the “Internet of Things” to mean any project where you connect something to the internet you don’t normally connect to the Internet. They are often little gadgets: sensors and actuators (but not always). And in any reasonable interpretation of the term, you can use Machine-to-Machine almost interchangeably when using Internet of Things. (The only real difference is if you use Machine-to-Machine it marks you out as having a Telecoms background, where our IOT guys tend to be more general Internet background)

My primary problem with the IOT community, however, is this:

Most Internet of Things Projects are actually Private Networks of Things

What I mean by this is the Internet (with a capital I) has at its core certain key principles, that are both key to its technical design and have been one of the critical forces behind its success. It is an unfortunate fact that most “internet of things projects” fail to address one or more of these principles.


All IOT objects must be addressable. In internet language this is by an URI (Universal Resource Indicator) . Even the language “universal resource” should give you confidence that URI were designed to be pretty general purpose and addressing an IOT object is well in scope.

Open ecosystem

If the universal addressing scheme allows us to find the objects, once we have found it can we get in? How does the access work? This is a complex issue, and obviously there are profound security, policy and privacy issues to be considered, for normal web site as well as internet enabled devices. But it seems clear to me that the technical foundations on which an IOT network is based must at least support an open access schema, even thought this may not be the standard way the networks are deployed


If I have found the object and can access the object, the next question is what can I do with this object? The internet is a massive network of highly interoperable website (with content) and browsers that can access this content. This massive resource, this dynamic ecosystem of suppliers and consumers of information is only possible through rigorous, but flexible protocols and data formats. A compelling IOT ecosystem requires standards.

Openly defined (open governance)

Who owns this standard? Where is it created? If you are connecting to object over the internet, using a standard generated, owned and maintained by a single company, it can in no way shape or form claim to be and IOT project operating on Internet principles. (But of course it’s not easy to do collectively, and it takes time)

Royalty Free

Finally, and in my opinion, most importantly, these standards MUST be royalty free. This feature has been (again this is opinion here) the most significant factors in the success of the internet to date, more so even that the elegance of its technical design.

I’m sure there are more I have missed, but this is a useful start; keep these principles in mind next time you see a project claiming to be an “internet of things project” see how many boxes it ticks.

webinos as a Internet of Things framework


Some of you may have read the recent BBC article “Open-source project to get gadgets talking via the net”. This is clearly putting webinos out there as a potential force (hopefully for good!) in the IOT space. But maybe a little more background here will help put things in perspective.

webinos started with a 4-screen objective: as a way of putting applications, using web technology, on to cars, TVs, PCs and mobiles. As well as putting the applications on the devices, we also had in scope the problem of getting these devices talking to each other

However, what rapidly became clear was that many of the problems that we had to tackle, namely security, policy, privacy, local networking, discovery and remote device communication, are equally applicable to smaller devices (classic IOT device) as the more fully featured Cars and TVs. Indeed, going back to the definitions above many existing IOT projects would classify a TV as home networking device and would by their definition have a TV as an Internet of Things Device already.

We made a decision therefore to extend our four screens with “screen zero”, the device without the screen. Or in more classical parlance Internet of Things or Machine-to-Machine devices. Concretely: we have our open source code stacks available as prototypes on Arduino and a number of demo applications, for which we will have some youtube videos uploaded shortly. The important discovery for us here was we could re-use the technical specifications we had created for our original 4-screen use case, and demonstrate its effectiveness in addressing an even wider problems space (IOT) without having to change any of the technical details.

Let us now to dive into some of the technical details, and look at exactly how technically webinos adds value to the Internet of Things Space.


Addressable = URIs

Key to webinos is the concept of a Personal Zone. Each personal Zone has a Personal Zone Hub, where the defining characteristic is that the PZH is permanent internet addressable. It is essentially a web server, with a strong identity (see below), through which all requests can be routed. This Personal Zone Hub represents an individual, who may have many devices. Each of these individual devices can be then referenced under the root PZH URI using the friendly name. This essentially give us a URI to address any IOT device, which when combined with the routing mechanisms described below, gives us a way of connecting devices to devices in a very robust way.

Discovery = Widget Feature URI + WebIDL

As you will see in the webinos design we have tried to always refer to pre-existing specifications and technologies wherever possible. This is why we chose the widget application packaging for application distribution (not necessarily because it was the best, but because it was agreed, standardised and royalty free, under w3c terms). Within the widget family of specifications, are mechanisms for describing and requesting access to capabilities, in other words APIs. This is an elegant and simple schema where each API is described by a URI. Again a Universal Resource Indicator, but this time instead of the URI referring to an object, it describes an API. This API is then specified at a greater level or detail using WebIDL, a well-established Interface Description Language for describing JavaScript APIs. Where we take it for granted that of you are programmatically accessing capability on devices over the Internet, you are going to use an Internet friendly programming language: that is JavaScript.

To add remove discovery to webinos we therefore took the pre-existing feature-URI schemas for declaring and requesting access to capabilities, and added some functions for making these requests across devices, as opposed to just calling for the feature on the same device the app is running on.

In the context of IOT this means that an object simply has to respond with the feature-URIs it supports when requested from a permissioned device

Invocation = JSON-RPC

Once discovered, we need scheme for remotely invoking and API and also a way for the object to hand its response back to the client applications. The problem therefore is how to package JavaScript for remote procedure calls. There is existing technology for this JSON-RPC which we simply reuse as is.

Identity = Personal Zone Key Infrastructure

At the heart of webinos is the PKI infrastructure. Our internet addressable Hubs and the many devices that may be attached to it need strong identities that can be used as the foundation for our communications. Moreover these identities need to be mutually attestable in the absence of visibility of the sever (hub). In other words my PC and my heart rate monitor need to be able to validate each other, even when there is no internet connection. It is hard to see how a robust IOT network can operate without this capability.

To deliver this within webinos we basically make use of pre-existing PKI technology and specifications, introducing some simple algorithms and processes for the enrolment of devices and the synchronisation and revocation of certificates within and across devices in personal zone hubs. In simple terms when you enrol a device to a PZH, you issue a bespoke certificate to that device that can then be used to bootstrap communications further down the line

Policy = XACML based

In any discussion of Internet of Things, the issue of security and privacy comes up a lot. Within webinos we have piggy-backed on a lot or pre-existing work in this area. The original solution comes from the IBM created XACML based XML policy description language, which has gone through several iterations, BONDI-> WAC->webinos, to generated a specific XACML instantiation that is fit for purpose for web based applications and internet of things deployments. Within the latest webinos versions of the specification we have included the best practice we could find coming out of the PrimeLife and P3P initiatives

The end result is that we have a highly interoperable (therefore synchronisable between devices) mechanism for describe the precise security, policy and privacy rules that a user wishes to apply to their device

Local Connectivity = PKI + Connection Management

How do we allow two devices to connect to each other securely over local networks? We have already covered one component of the solution to this problem that is the PKI infrastructure. We also have in place a connection manager abstraction, which means that a device can look at alternative connection networks, selecting the best one, then connecting to the destination device in the best way possible.

What this means is that when you have two devices that need to communicate whether TV&Phone or PC& EnergyMonitor, they are able to do so obviously when both have full internet connectivity, but also when there only local connectivity (Wifi, Bluetooth, NFC etc) . Whatever the physical connection, and whether it a a local or peer-to-peer connection we can still use the same identity schema (PKI) to connect the devices

Security = TLS

Considering that we are using PKI as the identity model, it will come as no great surprise that we are using TLS as the connection scheme through which we tunnel the application communications.

It is on this aspect where there may be few optimisation tweaks for IOT deployments. TLS is obviously the preferred connection scheme and appropriate for most deployment scenarios, but some IOT devices are very constrained indeed in terms of their computing power and TLS can be computationally very expensive. There are some scenarios therefore were a more lightweight connection scheme is preferable.

Efficient Symmetric communications = TLS+ JSON-RPC

Classic HTTP/HTTPS which has browser s and servers is an asymmetric protocol: the servers are long lasting and presently available, the browsers are temporary, they make connections then disappear. HTTP is technically a “stateless protocol”. This is not ideal for IOT deployments: sometimes the IOT device will request the connection, sometimes the PC or management device. They are peers not client and server. This can be, and sometimes is emulated by having two sets of browser and server, pointing at each other, on the two devices in question. But this is far from ideal. By using TLS as the base protocol and tunnelling JSON-RPC over it, we have a very streamlined connection protocol that is both efficient, and can be used in either direction.

Interoperable = existing standards

The above list maps the challenge to specific protocols (largely pre-existing). The ensemble of these specification defines the base of the interoperable standard that is need to produce a vibrant ecosystem where any device can connect to any device.

Royalty Free = W3C IPR policy

And to address the royalty free issue we raised at the start of the article, these specifications, under the terms of the webinos engagement agreements are delivered on the understanding that these can be put forward to W3C as candidate specifications. Each contributor explicitly recognises this intent and direct references are made to the W3C patent policy.

Ease of Deployment = Apache 2.0 Open Source

webinos is of course more than just a set of specifications, it has a full open source implementation that is made available on a number of different platforms, including the IOT focussed Arduino platform. This code is made available under the Apache 2.0 Open Source license, making it fairly easy to use for commercial adoptions

Embedded Server = node.js

To deliver IOT you need the logical equivalent of a server running on a device: an embedded server. Within webinos we looked to see what projects out there could deliver en efficient but extensible server framework, but would also be readily adaptable to out Internet programming Language of choice: JavaScript. Node.js is the obvious candidate here and specifically within webinos we have taken the node.js core and overlaid a set of applications on the top to make it operate effectively on PC and mid-range devices. To date this strategy has proven remarkably effective giving us not only a server framework ready to go, but an application framework that is highly portable over many operating systems.

In addition to PC, Mac and Linux, we clearly have Android in scope as a target platform. Unfortunately node.js does not run out the box on Android. Certainly not on unrooted Android devices. One of the webinos contributors (Paddy Byers) set about porting node.js for unrooted Android and we now have the anode project as a result, on which the Android version of webinos is based.

Extra small scale deployments = microPZP

For some IOT deployments this will be enough; for others node.js will be too computationally heavy for deployments. For these scenarios we have developed the notion of a microPZP. A microPZP has all the same functions of a normal Personal Zone Proxy, and is in its entirety an embedded server. The difference is that is has been compiled from raw C (not a virtual JavaScript execution environment) and has been tuned for the particular embedded environment. But as long as it supports the core functions of

  • Mutually authenticated TLS based on pre-shared Certificates, according to the webinos PKI infrastructure (or an optimised implementation with similar behaviour)
  • Responds to Feature-URI capability discovery requests, to tell attached devices what functions it supports
  • Responds to JSON-RPC requests

Then it is possible to create highly interoperable, secure IOT deployments, with will interoperate in large eco-systems.

Open Governance = Free affiliation

Final, point which is non-technical, but no less important because of this. Webinos runs as best as we can manage, along open governance principles. What this mean is the totality of the webinos specifications is far more than the product of a single organisation (to date 30 organisations have been involved in its creation). It also means that anyone out there reading this (whether an individual or company) can also take part and influence its future. All we require is the commitment that allows us to maintain our open source code base and the royalty free status of the specification. There are no webinos joining fees!


We hope this article puts a little more meat on the bones, in terms of understanding exactly how and why webinos is relevant for Internet of Things technologies, and if you have any feedback positive, negative or simply more questions you would like answering, feel free to comment publically on this site, email the consortium at or myself at