What follows is a post I wrote back in April for my co-workers who are tasked with sales and product concerns. I am posting it because it still applies to our present situation in IoT, how we got to where we are, and what direction we are moving.

The OCF is an attempt to address these problems, but in my opinion, their specification requires more options for protocol apart from CoAP.

Nevertheless, I think they have provided ample specification to address the fundamental problems I outlined back in April.

But I will hold those analyses for a different post.

From: Ian Lindsay
Date: Tuesday, April 19, 2016
Subject: The hard problems

You wanted a list of the hardest things in the IoT space. This will largely depend on your audience, but these are all unsolved problems. These are all software concerns, so if you are talking to hardware vendors, I would think that for them to partner with us would be largely a matter of showing them that we have good solutions to these problems without too-badly impacting their designs or business strategies.

  1. Application-layer “AKA: end-to-end” security: “Security" is a two-sided problem… Authentication (a wax seal on the envelope, or a signature), and concealment (“crypto” is from the Greek word for secret). These are largely solved problems at the transport layer (IE, "protecting the wire" [DTLS, HTTPS]).

The trick is to make that security carry past the couriers of the communication, such that only your intended endpoint understands you, despite having many independently-secured wires forming the path.

  1. Policy implementations and “Identity”: These are two separate issues that (like auth and concealment), are linked at the hip. Most everyone I talked to and heard from wanted control without connectivity. This might mean your local gateway is alive and accessible, but there is no internet. Most seem to me to want the option of access-management and data-access from the cloud, but without strictly depending on it.

  2. Shared concepts of data and application semantics: Is my idea of “apple” the same as yours? Does your definition include “red” (whatever that means), average mass (in what unit system), expiration date (with what notation of time). Etc…

The problem is exactly the same for application semantics, but instead of sharing data, it involves giving and taking orders. If someone tells me “Make me a sandwich”, everything else is left up to me. Does “make” involve combining ingredients, or simply collecting them in one place? How do I tell the other guy I do or don’t understand him?

My code can ask itself these questions, but cannot ask other vendors’ code the same questions. Or it can, and the answers are more variable than I can cope with. Or not deep enough. And unless I have answers to those questions, I cannot interoperate.

Hardware vendors are often in the position of writing their own verticals. This sucks, and most of them seem to know it. Many of them have done so because there is presently no other good option. So they will probably value inter-op for the value of “not having to re-invent the use-cases”, and may not be at all concerned with the minutia of the three issues above, as long as it can be solved for them.

When building hardware, I make choices based on my BOM, and my perception of what the software stack will want, rather than engage in what amounts to “market research” in areas unrelated to my product. I will always miss something. Possibly something lucrative.

Conversely, software vendors see practically everything as a “brownfield” device that must be wrappered to accommodate their goals, assuming it doesn’t outright dictate their stack. They have no direct means of providing feedback into the hardware people with respect to their desires from the hardware, and are commonly mired in numberless layers of wrapper that a variety of hardware vendors have dropped in their lap (mostly without any mal-intent). Some teamd manage to navigate such a mess, but many companies wouldn’t be able.

As I see it, the value of the inter-op to a software company would be to allow them to plug into well-established ecosystems, data repositories, and markets that would otherwise be “that boilerplate that we also have to do”.

And it doesn’t even have to be a “whole framework” sort of affair. It may be that your customer only cares about point 3. Or points 1 and 2 (which often come to the party together).

Broadly, all of these issue are hard because they are all intertwined. I’ll write up some of the potential solutions and why these are hard problems later. Or you can come chat me up about it.

—Ian