Position Paper for the IoT Semantic Interoperability Workshop Considerations for certain IoT based services Ben Campbell Robert Sparks 1. Who owns IoT devices? End users often purchase consumer-oriented Internet-of-Things (IoT) elements as they would any other home appliances or tools. They expect to own such devices the same as they would any other purchases. This ownership interest implies that users should be able to control how those devices share information, what services they work with, and what features are enabled. Users expect devices that they own to continue to be useful for the reasonable future, even if the manufacturer decides to terminate service. 1. Trusted Services for Device Control Many smart device products and related frameworks, especially in the home automation market, use a "cloud-based" control model, following the "Device-to-Cloud", or the "Device-to-Gateway" patterns [RFC7542] where the gateway must communicate with the cloud for normal operation. For the purposes of this discussion, "cloud-based" means that the device monitoring and control framework is hosted as a service, either by the manufacturer or a third party. Devices typically communicate to the service across the Internet, while end users interact with the service via web pages or mobile applications. There are several motivations for application service providers to adopt a cloud-based approach. Hosted services can offer benefits to the end user. For example, cloud-based frameworks often provide remote access, integration with automation services such as [IFTTT], and automatic backup of device related configuration and data. And of course, providers get to collect valuable information about user behavior. Cloud-based services make customer lock-in easier. But there are some serious privacy related downsides to the cloud-based approach. Cloud-based frameworks often force end users to trust application service providers with their data. Home automation data can paint detailed pictures of user habits. For example, energy usage data alone can indicate when users are at home or away, awake or asleep, on vacation, or even bathing[Tien]. Adding lighting patterns, thermostat settings, coffee maker operation, and television viewing data can reveal much more. Providers take on the responsibility for that data, with potential liability for any misuse [O'Brien]. Recent events suggest that the application service provider may become a target for subpoenas [O'Toole]. Even application service providers that protect the data from inspection by the themselves through encryption can capture information using techiniques such as traffic analysis. If a cloud-based service becomes compromised, attackers could gain control over home automation devices, even to the point of unlocking doors and turning off alarms en masse. If the service or the user's Internet connection fail, the user may completely lose device control. End users need to be able to make rational choices about the information they share with application service providers. Cloud-based services are often offered on an "all-or-nothing" basis, where customers must either share the information, or not to use the service at all. 2. Local Device Control Many of these issues can be mitigated with a "local control" approach, where the control framework is hosted on premise. In the case of home automation, device control would be executed on devices or systems physically present in the home. With locally controlled frameworks, users can minimize the data that leaves their homes in the first place. It reduces the opportunity for mass compromise of home-automation devices. And it can continue to operate when the user's internet connection fails. Application service providers can still provide rendezvous services to allow users to securely access locally-hosted services from remote locations. Providers can provide automatic backups of encrypted data without having access to the clear text. Integration with third-party automation frameworks such as IFTTT is still possible with a mixed approach. This suggests that even services that are primarily "locally controlled" will have some features that require sharing data with the cloud. Users need the ability choose whether to use such features, so that they can control what data is shared. This choice needs to be reasonably granularly; a choice between "enable all cloud features" vs "disable all cloud features" is not very satisfying. 3. Customer Capture The aspect of "capturing" the customer is often key in building business models around home automation services, and in general, any service that use IoT elements. This pressures design decisions towards tightly controlling how the elements can be accessed. "Captive" deployments force the elements to contact a central service, and do not allow direct access to those elements without going through the service. 4. Service Lifecycle Such deployments, particularly when the central service is cloud-based, risk overlooking several important operational life-cycle scenarios. It needs to be possible to make significant changes to the service infrastructure, such as underlying cloud technologies, without abandoning deployed IoT elements. Designers need to consider how deployed elements should behave if the service is suddenly and permanently disabled, gracefully retired, or merged into a different service. As was the case with hard-coding IP addresses and DNS names into applications, there is a high potential for surprising consequences when elements assume the central service will always be there [RFC7452]. This potential is amplified as the number of participating elements increases, particularly those that are difficult to physically access. 5. Impacts on data and information modeling The information and data models for managing IoT deployments need to include the concepts that allow changing how and when the IoT elements interact, particularly with centralized services, to address both short and long term service outages, changes in fundamental service infrastructure, and the potential for service retirement. The models should allow application designers and operators the flexibility to separate components of data control into logical containers for management, allowing different policies to be constructed for handling local information, and information that needs to be made available to remote services. References: [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, "Architectural Considerations in Smart Object Networking", RFC 7452, DOI 10.17487/RFC7452, March 2015, . [IFTTT] https:/ifttt.com [Tien] "New 'Smart Meters' for Energy Use Put Privacy at Risk", EFF Deeplinks Blog, March 10, 2010, . [O'Brien] O'Brien, H. Michael, "The Internet Of Things: Liability Risks For Tech Cos.", Law 360, July 20, 2015, . [O'Toole] O'Toole, James, "Cops can access your connected home data", CNN Money, June 16, 2014, .