It is easy enough to say that, in the Internet of Things, things will have identities. (It must be easy because every identity management vendor appears to be saying it). Toothbrushes, toasters, jet engines, HVAC units -- each will all have an identity.

But just what does a thing having an identity mean? To explore that, let’s think about what having an online identity means for ourselves. Consider three key online use cases that involve identity: sending an email, logging into a website, and authorizing a website to access your information stored elsewhere.

When we send an email to a friend or colleague, we enter the person's address into our email client, type the message content and then click send. Our mail provider's servers, based on the domain of the target address, determine how to route that message to the corresponding server at the other end, where it can be subsequently retrieved and then read.

We don’t think about it, but the @ in the email address implies that email works across email providers. (It didn’t initially. There were islands of email.) There is significant invisible (to us) resolution infrastructure making that interoperability happen. Similar magic happens when we enter a website address into the browser URL bar -- the name format that we find convenient in referring to websites is not what the IP network uses -- and lots of invisible infrastructure works to resolve between the two.

Depending on the use case, things may require the same sort of cross-domain interoperable addressing. How we name things will matter, and in the absence of a single global registry of such names, we will need mechanisms to match entries between multiple similar registries. When we log into a website, we (typically) present a username and a password -- both established with the website in a previous registration step. The site compares the presented password to its copy and if the two copies match, grants us access to the corresponding account data.

Human evolution & SSO
For humans, passwords are challenging. Evolution has wired us to find it easier-to-remember gossip and stories about hunting bison than strings of characters, so we cheat by choosing the shortest and easiest to recall we can get away with. Federated Single Sign On (SSO) systems replace passwords with standardized security tokens, which are issued by some other website to which the user actually directly logged on, and so serve to mitigate a full password explosion.

Things will also need to login to each other, to local gateways, or perhaps to cloud servers. They will do so by including some sort of secret authentication credential on their messages to those other actors. The SSO model is also relevant to things, but not because of a thing’s limited memory. Things would have no problem remembering passwords like "jH6Gf!e6Bf@." But even for things, passwords are less than ideal. Would a thing need to establish and store a different password for every other party it might interact with? If so, the resulting cache of passwords would be an attractive target for hackers.

The federation model will be relevant to things because it will allow things to authenticate to other actors in different trust domains, i.e. to actors with which the thing does not have a direct relationship. In a federated world, things will directly authenticate to some authentication authority (perhaps on the cloud) with an existing credential and receive back in response a different (authentication) token to be used to authenticate to other actors. This model would, as an example, allow a Nest thermostat to send a "close" message to a garage door controller from a different manufacturer if it sensed the temperature dropping.

Another common identity use case these days is for a website to ask us for permission to access our account information stored at another website, the data flowing through API calls. To do so, the requesting website must be able to present some sort of proof to the API endpoint that it is acting with our consent. The current best-practice model has the requesting site asking the user to consent to the hosting site with a security token that represents the user's consent for some operation (e.g. read the user's Google calendar) to be performed against the API.

That dynamic may also be relevant to the IoT. Many things will be operating on behalf of a particular human, or set of humans. For example, my Fitbit Flex sends my step data up to the Fitbit cloud, not some other user's data. That relationship could be captured and expressed via the delegated authorization model. The user would facilitate the issuance of a security token from the Fitbit cloud to the device. This token would then be used on subsequent API calls to identify to the cloud the combination of thing and user. Also important, this model allows the relationship to be broken when appropriate, such as if the Flex were lost, stolen, or sold.

Like us, things will have identities. They will have identifiers and addresses and will need to be authenticated. They may even act on behalf of particular users.

Patrick Harding is responsible for the Ping Identity product and technology strategy. He brings more than 20 years of software development, networking infrastructure, and information security to the role, which includes oversight of the Office of the CTO and Ping Labs.