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).