9E/ Identity & IoT / Phil Windley & Andre Priebe
Session 9D
Identity & IoT
Session Convener: Phil Windley & Andre Priebe
Notes-taker(s): Neil Thomson
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
What is the need for IOT and Identity
Identity is need for data traceability (from the IoT device), for upgrade, configuration and management access, and control (active device, as opposed to a passive sensor.
Identifier vs Identity
- Identifier is (possibly) the serial number on the housing of the device
- Identity may be “bathroom light”
An issue for devices (including smart home) is providing a device with permission/authority to act either on behalf of the (home) owner on it’s own behalf (order consumables or maintenance parts).
Identity is also key to managing relationships with devices. Note that a device may be in several networks or accessible by multiple entities. Example: an appliance may be directly accessible by the home owner, the home automation application and a maintenance/service which monitors for faults or routine service needs.
There is also the consent of a digital twin where most of the computing power and metadata information about the device may run on a server - e.g., as a “digital twin”.
See the diagrams, below:
Discussion: Control over FitBit data
IMAGE
Discussion: Different types of devices, digital twins, authentication and qualified relationships:
IMAGE
Advice for managing relationships between users, organizations and devices: Don’t try to use existing and established protocols at any price - better design the protocol and figure out what is already there.
Many IoT devices are not upgradeable, so may need smart, upgradeable aggregation/management hubs to provide for network security, and also as a host for additional computational power for low level/basic IOT devices
Capabilities need to be known, including what a device can do with and without authorization to act on its own.
There are several models for IoT devices communicating. As an example for a FitBit Device.
- Fitbit IoT device -> FitBit corporate server -> users server, phone or laptop
- Fitbit IoT device -> users server or phone -> FitBit corporate server
The first essentially puts the FitBit corporation in charge of the person’s data as it is the first to receive data from the IoT device, and is the actual FitBit configuration. The second puts the person in control of data/privacy
Discussion on MATTR
What is the role of a back end or phone in IOT - could be for storage, could also be for computational services beyond what the IoT device can do on its own.
Identity (vs Identifier) may be handled by the back end.
- Authorization provider
- SCIM
- OIDC provider
May also have a digital twin on another server. So the “whole device” may be a distributed device.
Use Case for a supply chain - where a device may be included in different chains with chain specific identity (and possibly identifier)
SPIME - Science Fiction author Bruce Sterling concept - Space and Time
- Gizmo
Everything has a unique identity through SPace and tIME
Principle is to trace the “life” of the item from creation/birth to destruction/death.
The smarter things get the more interesting data can be collected over time.
How to you correlate/synchronization of the device with its “digital twin”
Picos - persistent compute object - Phil Widdley concept
Can get IoT devices - which can capture and transmit (e.g., bluetooth, cellular network)
Car Area Network (CAN).
Device in a car to monitor car activities/events to see what information was gathered and what interesting information you can provide to the car owner.
CAN Bus never considered that external devices or agents could get external access for remote control (bad assumption).
Somewhere @ Tesla, they have a connection to each car - have a model to each car - which sync both ways - Another example - aircraft jetliner engines - have been digital twinned for years.
Another example - Amazon auto cashier - you just take things off the shelf and are automatically debited.
Digital twin is where most of the smarts and storage is - the IoT is there ofr inputs and outputs - a remote I/O channel capability.
There can also be a digital family - a fleet of vehicles - a both individual and a composite object (With their own operational data and aggregated composite).
Another feature for digital twin is that other users can have access, but restrict what information is released.
“I just bought your smart-house, now what”?
- Does the new owner have full access?
- What about the former owner?
Giving up a car or house, will also give up the history, which you may want to extract prior to ownership transfer.
Then there is selling the data collected from smarthome devices to appliance manufacturers, usage patterns, social information.
An issue of providing permissions to the device to act on your behalf. Risk of having to give too many permissions for the functionality wanted by the user (e.g., giving out the credit card).
Does a device belong to a single “controller” or all the people in a family or by the family and some outside agency (that manages a device for maintenance reasons).
Example: weigh scales - who do they disclose the weights to - only to the individual - how would the weight scale know the difference (without identifying each individual)
Another example - shared TV - how to handle multiple users/viewers
Problem of rental cars - which share driver/renter information with many different services (including your contact list).
How does that interact w SCIM.
Providing a toolset ow to model and link devices and back/ends/digital twins via different communication channels.
Protocols talked about are not compatible with more complex interactions and relationship use cases.
Manufacturers are taking “simple” use cases. Selling device for someone who uses it, which would be very different for a TV sold to a hotel vs. an individual.
Manufacturers have not worked through the more complex use cases.
Sounds like a need for a raw i/o interface where the back end
What is the gap between MATTR and other things.
Most of that is the complexity of the relationships and inclusion in higher level processing/uses.
Cars and their smart systems were designed for a small number of users over 15 years vs. daily different users for 4 years (as rental unit).
That level of engineering is beyond the manufacturer.
There is the problem of upgrades - for lost cost devices there will never be security upgrades - which leaves security gaps as a long term risk.
If leveraging the full capabilities of IoT is complex then they won’t be useful.
Classic techy dev assuming that users will also be techy is endemic.
Capabilities like this have been available for a long time, but not generally known about (or usable) by your average consumer
Toasters getting security upgrades - for toasters - burn ads into the toaster to provide a revenue stream to afford the ability to upgrade.
