IEEE Consumer Electronics Magazine - July 2015 - 57

tasks the user expects of it. Note that this problem is not
mitigated by the device having a proxy.
Connected-car scenarios also point to other problems with
connected devices and OAuth's dependence on a user being
present. For example, what happens when Alice lets Bob borrow her car? How does she grant access to Bob? Can she
limit what Bob can do? What happens when the device cannot communicate with the AS? These problems can be solved
in a variety of ways, but if every device manufacturer solves
them differently, we will not create an interoperable IoT.
In the case where both the device and the client are under
the control of a single authority and trust each other, Hannes
Tschofenig has proposed an extension to the OAuth client
credential grant that uses CoAP and DTLS for connected
devices [7]. In this scenario, the client uses client credentials
(which are relatively stable compared to access tokens) to
retrieve and access the token from the AS. When the device
API is queried, the device receives the access token from the
request and validates it with the AS. If the access token is still
valid, the device returns the desired data.
This solution leaves the user out of the access token grant
process and so cannot be used when the client needs access
to data on a user-by-user basis. In Fuse, for example, we
wanted to preserve the ability of the car owner to invalidate
Fuse's access to the data from the car. Consequently, a client
credential grant was not appropriate.

MAGICALLY WORKING TOGETHER
Even with the preceding problems, OAuth still presents a viable solution to a lot of present-day IoT challenges. Still, supporting a world where dozens or even hundreds of connected
devices easily connect together to get things done for their
owners will need more than what present-day OAuth is prepared to provide.
Mike Schwartz of Gluu calls this the "magically working
together" problem [8]. Schwartz uses the example of a connected light bulb and switch, as shown in Figure 3. He says,
"If you buy a light switch and a light bulb, they need to magically work together." In this scenario the light bulb is the RP
and the switch is the client.
Getting connected devices to directly work together is difficult. Commercial connected lightbulb products like Philips
Hue use a hub and a proprietary connection system. But it
seems unlikely that any of us will be willing to buy all of our
light bulbs and switches from a single vendor, let alone every
connected device we might ever own.
A more general solution would use a suite of standard
protocols for managing the interactions that can be supported by devices operating alone or with a hub. OAuth could
play a role if we overcome some of the obstacles that currently exist.

TIERED ACCESS CONTROL
One key idea in a flexible connected-product scenario is support for tiered access control with fallbacks. (These scenarios
are not about identification and wiring. We are talking strictly

FIGURE 3. Connecting a light bulb to a light switch.

about access control, not how the switch knows which bulbs it
controls. Other standards such as OpenID Connect aimed specifically at building identity layers on top of OAuth will provide important capabilities for device registration and
discovery.) Without tiered control and fallbacks, a deeply connected set of devices would be prone to failure through the tyranny of overactive access control whenever network
connections fail or hubs go offline.
When all the devices are members of a trusted network,
we may not need any access control. These situations are
usually rare, especially where wireless networks and dynamic
device situations are in play.
If the devices and clients are relatively static, then client
credential access control may be appropriate. Client credentials are easy to set up and may be preprovisioned. Transferring the credentials from one device to another during the
setup can be accomplished in various ways. Once the device
has the credentials, presuming that they are not subject to disclosure, they can be used in a static environment indefinitely
to grant access to a device. This is essentially the same as
giving each device a username and password.
OAuth tokens support devices and clients that come and
go. As an owner uses new devices and applications, OAuth
supports granting and denying access based on the owner's
whims. There is an inconvenience, however, in the fact that
each RS might have a different AS with which the owner is
responsible for tracking and interacting.
Devices could be smart about falling back to less restrictive
access control policies to ensure that they work even if they are
not connected or the user's phone is not charged. The fallback
policy could be configurable to avoid situations where a security problem might result from falling back too far.

USER-MANAGED ACCESS
When you have just a few things connected in only a few
ways, keeping track of what device is sharing what data with
who might not be easy, but it creates only a small risk. As the
number of devices and connections increases, however, this
becomes a significant worry.
User-managed access (UMA) is an emerging standard that
can be thought of as OAuth++ because it adds two very
important elements to OAuth [9].
1) UMA specifies a formal protection API presented by the
AS so that RSs running in different domains can be
"authorization relying parties" to it. This feature allows an
AS to be under the device owner's control instead of the
july 2015

IEEE Consumer Electronics Magazine

Table of Contents for the Digital Edition of IEEE Consumer Electronics Magazine - July 2015