Discovery for IoT

Premise is that the IoT would have us awash in services advertising us of their availability.

So, how to filter this sea down to something useful & manageable?

Via filters determined (mostly) by the context of everything else we have going on - what searches we've performed, what events are in our calendar, what we've recently bought, listened to etc etc.

Those services that meet the criteria are allowed to prompt us (via applications?) for interaction.

Identity, application models & the Internet of Things

In a blog post entitled 'Mobile apps must die', Scott Jenson argues that the Internet of Things (and the associated implication of having to interact with all the 'things') will make the native application model impractical, and push application development back to the browser.

I buy the argument, will repeat some of it and will try to tease out some of the identity implications.

First, a bit of a recap of Scott's argument (or my interpretation at least)

• Whereas on a desktop we might have had ~10 installed apps, on a phone or tablet we might have ~100. Users have to manage this list. It is trivially easy to install apps from the app stores. That’s great from the app developers PoV, it minimizes the pain of installation and so allows for Users to play and experiment. But from the Users PoV there is a price to be paid for easy experimenting – the application remains. SSO between these apps helps but the problem is bigger than just authentication.
• Offline mode will become an antiquated concept as connectivity becomes ubiquitous. ‘CEO on a plane’ will disappear as an important use case when every plane has wifi. Consequently, the current advantage native has over browser models with respect to supporting offline via device storage will become less relevant.
• As more and more objects become connected (IoT), the nature of mobile applications (through which we’ll interact with those objects) will have to change accordingly. When my fridge, dryer, furnace, air conditioner, microwave, and thermostat etc are all connected and desperately want to interact with me – do I want a unique app for each of them? And what about objects outside the house – coke machines, point-of-sale terminals, bus stops schedules, restaurant menus, gas pumps etc

So the Internet of things would push us to have 1000s of native applications on our devices, but that would place a completely unrealistic management burden on the User – installing, authenticating, sorting, updating, & deleting of applications when no longer needed etc.

The problem is that the current native application life-cycle looks like

1. Discover
2. Install
3. Authenticate
4. Use
5. Update
6. Remove

This sequence places a heavy burden on the user and is very static – not particularly applicable to a ‘Just in time’ model (as Scott puts it) where I might interact with an application once and never again. 

Clearly this isn’t viable in an IoT world where we will constantly be presented with previously unseen connected objects. We’d spend our days installing apps and by the time we were ready to interact, the opportunity will have passed (somebody else would have grabbed the last Dr Pepper etc)

IoT demands an application interaction model that is far more dynamic, something like

1. Sense – my device must be constantly on the lookout for IoT connected objects and, based on rules I’ve defined, determine whether & how best to interact with them
2. Notify – based on rules I’ve defined, prompt me to know that I can now interact with the object
3. Authenticate – the object may need to know who I am, but this obviously has to be seamless from a UX PoV. (the object may have to be able to authenticate to me as well)
4. Use – I interact with the object. This can’t require an ‘install’, instead whatever unique application functionality must be downloaded and run in an existing app designed with this sort of flexibility – ie a web page running in a browser
5. Cleanup – as there was no install, there are no artifacts (except perhaps some state to simplify the next interaction) to be cleaned up, ie no uninstall

The Internet of Things would appear then to be pushing us towards a future where

• The pendulum swings back to the browser (& so HTML5 comes into its own)
• The importance of browser means Web SSO remains relevant
• For Web SSO, SAML gives way to OIDC due to its support for Javascript-powered apps running in the browser and pulling data from APIs offered up by the 'things' (or network endpoints on their behalf)
• SSO (in the sense of facilitating seamless user authentication to all the various IoT objects) is absolutely critical. 

The last can be summarized as 

IoT won't scale without SSO to the T.

Imagine I have a smart toaster that I want to interact with on my phone to determine if I need to empty the crumb tray (this needs to happen Science!!) 

How

1. does the toaster advertise its presence to the phone?
2. is the user invited to interact with the toaster?
3. toaster data (crumb tray status etc) get sent to the toaster cloud for analysis
4. toaster data (crumb tray status etc) get sent to the phone for display

This diagram is a really rough attempt at a model

The toaster serves up crumb tray data (& some javascript) to the device browser. The javascript interacts with an OAuth Authorization Server (we can get the User consent at this point) and obtains an OAuth access token that represents the combination of toaster & User. The javascript then uses the access token to upload the data to an associated TAAPI (Toaster Analysis API) for analysis and then renders application UI to the user based on that analysis (eg ALERT - CRUMB TRAY DANGEROUSLY FULL).

The Quantified Self & Application Scale

As part part of the self-quantification (QS) movement, there would appear to be a pairing of measuring device & associated application for every aspect of personal health - diet, weight, prescription medicine, fitness, blood, breathing, GI tract health, etc.

Devices measure the various X (some passively, some actively), and the associated application, once installed onto a phone or tablet, displays and analyzes the collected data for the user - presumably to help them make health decisions in the direction of longer life (and so longer duration customer for the application provider).

When each health aspect has its own device, and each device has its own native application - the user will necessarily bear the burden of installing, managing, and authenticating each native application.

That may be an acceptable burden for somebody with 2-3 separate devices (and so 2-3 native applications). But what of the neurotic hypochondriacs? Or the paranoid new parents obsessing over each cough and sniffle of their new baby - both of whom might have > 10 health monitoring applications?

This hilites a key problem with native applications - their lifecycle (discover, install, login, use, manage, remove) doesn't scale particularly well for the user. App stores make the first two trivially easy (arguably too easy), but dont help much with the steps that follow.

The problem will only get worse when it's not only personal health monitoring devices that we will want to be able to interact with, but everything. When my fridge, washing machine, dishwasher, printer, garage door opener, mailbox, and TV remote are all collecting data and clamoring for my attention to view, analyze, and act on that data - do I want a separate native application for each of them? No I do not. 

If only there were an alternative to the native application model - one where application functionality can be downloaded in real-time, rather than a priori installed.....