Friday, May 24, 2013

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

5 comments:

Mark Dixon said...

What we need to get away with, whether using native apps or browser apps, is the one-to-one correlation between app and device. Why not one app to manage all the devices in the house, rather than a single app for each device?

Robert said...

I buy the argument for the pendulum to swing back to Web/HTML(5), and SSO and all of that. And I won't repeat it, not even how I understand it.

But why would a Toaster need a token or what would the user give permission for ?

Is it really the case that you don't want your Toaster broadcast to your wife that it's full of crumbs? Yes, surely she would conclude that you didn't clean it when it was your turn to do so, but she would know this anyway, wouldn't see ?

In the IoT I suspect that the main challenge is to set up rules that govern which devices are allowed to notify/interrupt me. On a Friday afternoon I do want to get notified about that happy hour offer in the bar nearby, and on the Saturday morning I do not want to interrupted by my Toaster. On Saturday, after lunch, I might be willing to act upon a message from my fridge (out of beer). Etc., etc.

Paul Madsen said...

@mark - exactly. But that implies a single generic management app that can expand to deal with arbitrary devices. And doesn't that sort of flexibility sound like a browser? ie an application framework client into which device specific functionality can be dynamically loaded?

@robert - the toaster (or any other sensor) has data - it has collected that data and will make it accessible for analysis & reporting. Toaster crumb data may not be particularly sensitive, but other data sets certainly will be - so in general a sensor will only release its data to authorized clients - thus the need for some sort of authentication & authorization token presented to it. Of course, sometime this authorization will be implicit - any client on the home wifi network etc

Agree that ensuring that users can control/limit interruption will be critical. Myself, I am going to hire a high-school student and forward all such messages to them for appropriate filtering.

Anonymous said...

My mobile comes with some must-have apps installed: mail, calendar, music, maps, to name a few. I can imagine this evolving to an IoT app, maybe tailored to some categories, like My Space (just couldn't resist) for the physical space around you, People for physical & virtual closeness, Offers to physical & virtually proximate advertising/coupons. Hmm... this warrants some thought.

Anonymous said...

My mobile comes with some must-have apps installed: mail, calendar, music, maps, to name a few. I can imagine this evolving to an IoT app, maybe tailored to some categories, like My Space (just couldn't resist) for the physical space around you, People for physical & virtual closeness, Offers to physical & virtually proximate advertising/coupons. Hmm... this warrants some thought.