In an interesting Medium article, Pat Burns debates (with some cheesy college beer-drinking humor) whether or not the Internet of Things (IoT) should break up with the cloud. It's not that the relationship has gone sour--it's just that sharing data between things and the cloud isn't the best for the long haul, what with the lag time and insecurities and all.
He states that in today's predominant IoT deployment model, devices push their data up to a corresponding cloud for analysis, interaction, and application logic. But he cites inefficiencies, insecurities, and potential lock-in of the 'always cloud' model, arguing that cloud collection and analysis should not be the default, but rather the exception.
A new golden rule of IoT network design is to store sensor data as close as possible to its point of origin and limit its sharing across the network unless absolutely necessary. This was previously not really practical with 1990s-era endpoint technologies. But today, if an endpoint can run its own analytics and other applications autonomously, what's the point of sending the data upstream at all, much less all the way to the cloud?
Of course, there are perfectly valid use cases for which the cloud needs to be involved:
Big data analysis, implying collection from multiple sources for a cohesive and integrated view (e.g., looking for electrical consumption patterns across a neighborhood).
Internal action triggering by external events (think of the often-cited 'open garage door as car turns up the street' use case).
Allowing Google to place ads for sweaters in front of you, as indicated by your preferred home temperature reported by your Nest.
But most people would agree with the fundamental principle Burns is advocating, namely that, when possible, data and analysis should stay local. In other words, if you can do what you need to do with that data right at the device, do it.
Burns also recommends a layered approach. If doing analysis on the device itself is impractical, introduce a gateway:
When endpoints are not enough, then add the edge. For processes that can't logically reside entirely at the endpoint, the edge gateway (or edge router or server) is their next logical home in the network. An edge gateway can interact with endpoints, host applications like analytics, store data, manage security, and more.
It's almost as if he offers the option of the cloud as a last-ditch effort:
When the edge is still not enough, it's OK to look to the cloud. The cloud has a role to play in the IoT. Where processes can't be practically executed at the endpoint or the edge, the cloud may be the only reasonable choice.
This hybrid model of device data staying local to the endpoint devices as much as practical, but being sent to a gateway or cloud when necessary, has implications for how the various actors authenticate to each other--specifically the credentials they use.
If a device always reports its data up to its corresponding cloud (the current default model that Burns is bashing), then it needs only a single credential to use for authentication of those messages. In a hybrid model, sometimes a thing interacts with other things--sometimes with a gateway, and sometimes with a cloud endpoint. How should it authenticate itself on those various interactions?
The simplest way would be for a given thing to be issued a credential that it uses on all messages to every other actor, whether another device, a gateway, or the possibly multiple cloud endpoints it might call. This global credential might be an X.509 certificate burnt into the firmware at manufacturing time, or perhaps a default password provisioned to the thing.
This sort of global credential is less than optimal. A single credential used everywhere makes correlation across those places trivial, and so potentially correlating the corresponding user's activities--not great from a privacy PoV. Additionally, if that global credential is compromised, it's not easy to minimize the consequences and damage--not great from a security PoV.
A better authentication model is for things to use different credentials for each messaging partner (or at least different categories of messaging partners)--whether other devices or cloud APIs. Multiple credentials inhibit correlation and allow for differentiated revocation. But of course, using multiple credentials necessarily implies mechanisms by which a thing can obtain those multiple credentials.
The possibility of a gateway 'managing security' as Burns wrote in the above paragraph hints at a potential model:
Device/thing shipped with a persistent credential provisioned at manufacturing time.
On deployment, device discovers local gateway and 'introduces' itself (in a conference presentation). At this point, I would wave my hands and mumble something about trust and attestation.
Using the persistent credential from #1, the device authenticates to the gateway and is subsequently issued a secondary credential. This token-issuance step makes a privacy-enabling step possible, that of a user being able to assign granular permissions to the thing for its interactions with other systems and applications (i.e., this Nest can control the furnace, but not the freezer).
The device uses this secondary credential when interacting with other local devices.
If and when necessary, the device can obtain a different credential from the gateway to be used on messages to cloud endpoint(s).
Here's a federated model, with the gateway playing the role of the token service (or IdP or AS, depending on your world view).
Issuing tokens to its constituent local devices.
Managing authorizations over the interactions of those devices.
Managing trust between the local devices and appropriate clouds and applications (likely with the assistance of corresponding cloud-based authentication and authorization infrastructure).
OAuth and OpenID Connect (and their various extensions) can enable the above authentication model. In fact, they already do this for the HTTP-based web. Work is underway (in the IETF ACE WG, amongst other places) to normalize how they can be applied to the device-to-device and device-to-gateway interactions.
Any data collected by Zuli is exclusively used to improve your experience and is never shared without your authorization. The Zuli app retains most of its learning and data collection on the device itself.
Of course, 'turn lights on when phone enters room' doesn't seem an overly taxing piece of learning.