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)