Smartthings - binding thing to user

Some 'things' need to be bound to a user identity in order to allow for differentiated authorizations or reporting.

Follows is how this binding works for Smartthings

I placed my order at Smartthings.com. When the package arrived, it included a registration code. I assume all the thing serial numbers (or equivalent identifiers) is indexed by that code as part of the packaging & shipping process.

Though I'm not sure, I don't believe the registration code was bound to my account at issuance time (even though it could have been because I was logged in at the time). Binding will happen post shipping.

I then download and install the Smartthings app (here Android). Below is the initial login screen

After logging in, I am prompted to plug in the Smartthings hub, connect it by ethernet to the home router, and then enter the registration code into the app

User account is bound to code, and code is bound to device identifiers - so consequently user account can be bound to device identifiers.

It is through the temporary identifier of the code that Smarthings is able to know that a given motion sensor is under my account and so apply a permissions model based on this binding, ie I can manage them but nobody else (unless I stipulate so). Even more basic, when the Smartthings cloud receives sensor data from a particular thing/hub combination, it is able to associate that data with my account.

I recently purchased a Fitbit Aria scale. The Aria used a completely different mechanism to associate the scale with my existing Fitbit account. Area seems ripe for usability testing.

Assurance over time

Consider a traditional authentication event.

The user logs in at a given time t₀ and establishes some initial level of assurance. As time goes by, that assurance drops, the rate dependent on the context, ie public kiosk, etc.

 A graph of assurance over time looks something like

 

To prevent this decline, you can require that the user re-authenticate whenever the assurance hits some threshold a_t

An alternative to using explicit additional logins (as above) is to maintain assurance above a_t by monitoring implicit factors such as location, continuous typing, facial recognition, etc

Nb: the 'how' of detecting & monitoring these passive or implicit factors clearly demands some new pieces on the network. Depending on where this functionality sits, we may also need new mechanisms & protocols for communicating the information around.

From the user's PoV, this passive model has advantages - minimizing as it does the pain of explicit logins.

Ultimately, using a combination of explicit & implicit authentication factors appears to be emerging as the optimal balance of security & usability.

I don't even drink milk!

Along with the smart toaster, a fridge that can sense when the household is about to run out of milk and send a compensating order to the local supermarket is presented as home automation's killer app.

Couple of things

1. Ahem, Webvan?
2. Lactose intolerance is a serious health issue for many

Now a fridge that could monitor 'beer' metrics - that's a use case!

And it's more interesting from an identity perspective. 

Any fridge can order milk. Only fridges that exceeds the local age of majority can order beer or wine.

Or more precisely, only fridges acting on behalf of a human who exceeds the local age of majority can order beer or wine.

That demands an identity model in which

1. The fridge can obtain an identity token for individual users - these to be attached to the 'Buy beer' API calls to the local depanneur
2. The token contains (or references) the user's 'age' attributes 
3. The token is issued from an identity provider that is accredited to issue age attributes
4. The depanneur can validate the token as coming from a trusted authority, look at the age attribute, and so determine that the fridge's request can be authorized.

OpenID Connect is tailor made for the above set of requirements. 

Users, groups & things

Below is an attempt to tease out a taxonomy of Internet of Things use cases - differentiating based on

1. on whose behalf the thing acts on (whether a data subject or not) 
2. the data subject of the data the thing collects & shares

A Fitbit Flex, Jawbone Up, Nike Fuel Band etc all collect the data of a given single user. It is that same user that the thing acts on behalf of. This makes for a pretty straightforward identity model - single device, single user.

At any given time, a smart scale like a Withings or Fitbit Aria is also representing a single user (and sharing that user's data). But, unlike the wearables above, for this sort of thing that user can change over time. Consequently, such a thing has to support multiple different users - including UI that allows users to select themselves from a list. Ideally, such a thing (and associated apps) would also support differentiated consent/authorization for all the different users. For instance, should my wife be allowed to see my weight data (and surreptitiously try to curtail my beer consumption as a result?) That's not a world I want to live in you, do you?

The archetypical 'smart toaster' would need this sort of identity model if it were to allow each breakfast eater to have personalized toast patterns.

A thermostat like a Nest, or a fridge, etc collects the data associated with a group of users (the family members) and can be said to act on behalf of the user that bought, installed, configured & registered it (not the teenager in all likelihood). Because the data is aggregated, the privacy risks are different than for a device that acts only for single users.

Things can also act autonomously, ie be 'doing their thang' not on behalf of a user of that thing, but for themselves (or more precisely some unnamed admin or even a corporate entity).

A residential electricity meter, like the Nest, collects data associated with a group of users (the family) but, unlike the Nest, is not under the governance of the homeowner. Instead the meter is owned and operated by the electricity provider. While the provider may give access to the homeowner, its fundamental purpose is to determine how much to charge per month.

Likewise, nobody would argue that a speed camera snapping a pic of me (only slightly exceeding the limit, which everybody agrees is ridiculously low on that stretch of road) is acting on my behalf. It's operating on behalf of the local region or county tax revenues. Along the other axis, those cameras can focus on (and differentiate) individual drivers or post-game hockey final loss mob members - and so create privacy concerns.

And probably the biggest use case (in number of sensors & perhaps $$) - all those factory floor robots, air quality sensors, street lights & water pipes silently reporting operational status.

Internet of Smells

If I've learned anything in 20 years of marriage, it is this

Hockey equipment must be aired out after use

Unfortunately every time the equipment is removed from the bag (enabling airing and thereby not negatively impacting marital complacency) there is a risk that it won't all be placed back in -  with almost certain consequences for pain & bruising during the next game.

What if every piece of equipment were able to report on its presence in (or more critically absence from) the bag as I pull it out of the garage?

How would the system learn that a particular piece of protective equipment was meant to be in the bag and, if not, alert me to that fact?

One model would be for me to manually specify a rule, ie 'At 6.15am on Tuesday & Thursday mornings, alert me if any of the 'Goalie Equipment' group of sensors are not within 1 m of the 'Goalie Hockey bag' sensor'.

Sounds like a lot of work (for myself).

Alternatively, the system could over time, recognize the above implied pattern, and build a rule itself alerting me whenever that pattern was violated.

Consent anti-patterns for Internet of Things

User-control will be key for many (but not all of course) Internet of Thing use cases. A key piece of such control will be collecting the User's consent for

1. a given thing to act on their behalf
2. a given application to access/control the thing

Follows are examples of (to my mind) 'bad' consent UI.

NB Although these examples are not IoT-specific, I believe the principles of what makes a good consent UI are still applicable.

Anti-Pattern 1 - Optional vs Required permissions

In the IoT context, what permissions are mandatory for the thing to have, and what are merely 'nice to have'? For example, if the thing is merely a sensor, dont ask for 'write' permissions.

Anti-pattern 2 - Unclear consent persistence

Will I be interacting with the thing going forward? or is this a one-night stand, e.g. allowing a bus stop to add the bus schedule to my calendar? Consent should reflect this

Anti-pattern 3 - Confuse The User as to Where They Are

Make sure the user knows to whom they are giving permissions.

Here is another example of confusing UI/UX. The Saga lifestreaming app has sent me to Fibit's site so that I can authorize Saga's access to my step data. But, because this is happening in a browser window embedded within the Saga app (as opposed to the default phone browser), its not clear that I'm actually presenting my Fitbit password to Fitbit.

Of course, just as important as providing the user intuitive mechanisms for granting permissions to things & applications is providing them a mechanism to view & manage (eg revoke) those permissions over time.

Anti-pattern 4 - Non-exhaustive list

Will the Saga app actually be able to see everything else other than my password?

Complexity asymmetry & constrained devices

Security protocols differ in how they distribute complexity between 'asserting party' and 'relying party' - and so will differ in how applicable they are to use cases where the two actors have unequal capabilities.

SAML assumes a relatively equal burden for the IdP & SP, e.g. both are assembling XML messages and may be signing those messages.

OAuth 1.0a, with its multiple tokens and client crypto requirements, likewise placed on the client a relatively high burden.

TLS can work in a symmetrical mode, one where both client & server are authenticated (and share the associated burden relatively evenly) and another where the client gets off easily (but doesnt get authenticated).

OAuth 2.0, and so OpenID Connect, was designed to move most of the complexity off the client. Being an OAuth 2.0 or OIDC client is pretty simple - assemble some HTTP messages, send them to AS via browser, keep track of some tokens, and add those tokens as headers on API calls.

So, for a constrained thing, OAuth 2.0 and OIDC make more sense than SAML (like I need to say that).

When you pair OAuth 2.0 with server-only authentication TLS (or DTLS?), you get

1. client authentication (via OAuth 2.0)
2. server authentication (via TLS)  
3. data confidentiality (via TLS)
4. data integrity (via TLS)

and, critically, keep most of the complexity off the thing and instead on the server or gateway that is likely more capable of bearing the burden.

Client-authn TLS provides all of the above security characteristics, but with a different distribution of complexity.

Identities - Thing & User

Things will ship from the factory with an identity - either burnt into the firmware or embedded into the software.

In home automation, wearable, & healthcare use cases, that thing identity will need to be associated with or bound to a user identity (or multiple user identities). Once this association is made, then any subsequent message from the thing can be understood to be occurring 'on behalf of' that particular user.

In theory this binding could happen before purchase by the manufacturer/retailer provisioning some sort of identity credential before shipping to a customer (with an existing account) but more likely is that it happens after the thing is brought home.

The binding mechanism can take different forms - it will depend on whether

1. the thing has a UI
2. the thing interacts directly with its Cloud, as opposed to via some computer/phone etc

The different mechanisms will place different usability burdens on the User.

For the Fitbit Flex, the binding happens via the desktop app

Once logged into my Fitbit user account from my laptop, the Flex messages with the USB dongle and presumably passes its device identifier - this to be passed by the desktop app to the Fitbit cloud for the association to be recorded.

When I receive my Smartthings kit (any day now), it appears it will be a more manual mechanism to bind particular devices to my user account

Regardless of how it happens, after binding the cloud associated with the thing is able to say that 'Thing with identity X is acting on behalf of User(s) with identity Y(Z)'.

How that association is manifested can also differ.

Very non-optimal (though I'm sure it exists) would be for the user's password to be handed to the thing (or to a proxying gateway) and used on its API calls.

Better would be an OAuth-type model, something like the following

1. Thing asks its cloud server for an access token , presenting its own identifier/secret
2. Cloud server logs user in and says 'You OK with this?'
3. Cloud server issues token to Thing (and remembers the pairing of Thing & User)
4. Thing uses token on its API calls to Cloud

The advantages of this model are

1. The user can be selective and granular in how they permission their things
2. The user can revoke the token when relevant (lost, stolen or sold thing)

OAuth for multi-thing coordination use cases

Let's say you have a Fitbit wrist band for counting your steps and a Nest thermostat for controlling your home's temperature (if you have both you almost certainly also have 3-4 iDevices but let's ignore that for now).

Both are great. Both give you visibility & control into areas of your life you were previously unaware of (blissfully or otherwise).

But both are oblivious of the other - both operate in their own silos, defined by proprietary APIs, and likely different choices for radio protocol.

Because of this balkanization, interesting use cases that require coordination of the Fitbit and Nest are challenging or not even possible. For instance, if after a brisk walk on a hot day I would hope to return home to a nicely chilled house - my steps as counted by the Fitbit would need to be taken as input to a rules engine that could send an appropriate temperature adjustment message to the Nest.

In the absence of the Fitbit and Nest stacks directly communicating, the only solution is to try to layer on the necessary coordination layer, as shown below

The coordination layer would use whatever external APIs Fitbit and Nest made available in order to a) query my steps via the Fitbit cloud and b) send a directive to the nest via it's cloud to lower the temperature.

Of course, the two different API calls would need to be authenticated as

a) coming from a valid API client
b) compatible with the user's preferences

OAuth 2 satisfies both of the above requirements - giving to the user the ability to

a) tell Fitbit what parties can see their step data
b) tell Nest what parties can control the thermostat

This sort of IFTTT-style coordination is a key value proposition of the emerging IoT platforms like Xively, Thingworx etc. Application developers can build on the platform, and need not worry about the specifics of how different devices integrated into to the platform, and be able leverage the resultant cross-device coordination capabilities. Of course (unless the platform scrape the login screens) Fitbit and Nest have to buy into the above scenario and actively allow 3rd party platforms to call their APIs (as opposed to only their own native applications).

If the Fitbit & Nest business folks were to get together to 'do lunch' and agree that there was value for both in more directly working together, then a different (and arguably simpler, at least in the near term) integration is possible. This is shown below

Here the user's step data is sent from Fitbit (not necessarily from the device itself, as shown) to Nest. It is at Nest that the rule 'drop temperature when steps equals 3000' was defined - Fitbit knows only that the user has authorized this integration - this consent manifested in the issuance of an OAuth access token from Nest to Fitbit. By including this access token on its API calls to Nest, Fitbit gives to Nest the information required to look up the user in their systems. The rules kicks in, and the Nest cloud directs the appropriate thermostat (mine not yours) to lower the temperature accordingly.

NB This model is 'simpler' than the platform model above because there are only two services to coordinate (and so one less account for the user to manage). In the long run however, such pair-wise coordination won't scale well. What happens when I want a G&T ready on the counter when I walk into my comfortably cool house?

Of course, beyond agreeing to use OAuth, Nest & Fitbit would also need to agree on the specifics of the API by which the step data was communicated. And while shown here as the step data being pushed from Fitbit to Nest (perhaps triggered by a subscription), it could be a pull from Nest, based on some polling schedule.

The mirror image integration is also possible

Here the coordination logic resides with Fitbit, and it is Nest that is relatively dumb. Nest would probably feel that there is a big difference between giving 'write' access to Fitbit, whereas in the previous scenario Fitbit needed only to give to Nest 'read' access. I guess the BD folks will work it over drinks at lunch.

However architected, OAuth 2.0 stands to be a key enabler of multi-device coordination in the Internet of Things.