Bezirk. W3C Web of Things Interest Group. Bezirk $$ $$$ 4/15/2016. April 11, Bezirk. user-centrism and privacy

Transcription

1 W3C Web of Things Interest Group April 11, 2016 is to the IoT what bio/organic is to agricultural products IoT that tastes better $$ $$$ mainstream business models revolve on the value of data for service providers user-centrism and privacy 2 1

2 IoT responsiveness device hub cloud-centric IoT 3 IoT reality check fragmentation Phillips BMW Bosch Google device hub cloud-centric IoT corporations consumer Data has business value little incentive to share that value 4 2

3 not all Data is created equal shared owned things you 5 mainstream IoT raw Data pumped to the cloud what does that mean to you? 6 3

4 mainstream IoT Loss of privacy cloud-centric IoT 7 Social reasons for boundaries shared owned reclaim the expected boundaries of privacy 8 4

5 Empower users to reclaim boundaries Privacy Who knows about this? Just you and I. policies cloud-centric IoT Quality: local integration Respectful: data ownership 9 Security model user-centric Spheres and Pipes Pipe to cloud Sphere: Bob s car Sphere: Bob s personal Bob s Home Entertainment Bob s Doctor Bob s Home Systems Pipe Pipes between spheres / to cloud secure channels for data & events requested by services, authorized by users policy enforced by middleware only authorized exchanges go through Spheres of trust boundaries of confidentiality managed by users create sphere, join service easy user experience balances usability & security 10 5

6 and WoT the story so far Introduces boundaries to the IoT for reasons: Social: privacy Technical: scope and scale Promotes Decentralized models with linked data Computation in local/mobile devices 11 Scope and Scale IoT is not the Internet device hub History: successful apps for the internet run on general purpose computers and access remote services e.g. , web browsing Now: must a sensor/appliance shoulder the burden of being a peer on the internet? e.g. access control, privacy must a sensor/appliance communicate primarily with remote services? our claim IoT give every device an IP(v6) address IoT topology should recognize and support two kinds of communication patterns: local and remote 12 6

7 Scope and Scale addressing a Thing landscape of addressing schemas address applications who receives node e.g (IPv4) geo e.g. (40.426, , 500) (lat, long, radius) topic label e.g. user location Internet routing: IPv4 (1981), IPv6 (1998) LANs: Bluetooth, WiFi sensor networks, safety & disaster response, transportation pub/sub: Java Messaging Service (message centric), Data Distribution Service (data centric) identified node sender must know recipient s address whoever is in the area whoever subscribes to the topic semantic: application defined network def. different addressing schemas solve different problems 13 Scope and Scale addressing a Thing resolving requests via semantic addressing (example: by topic) trace 1 trace 2 App (locateuser).(bob) (locateuser).(bob) User Location (getface).(bob) (userlocation).(bob,<here>) (getface).(bob) User Registry User Location (userface).(bob,) (userlocation).(bob,<here>) Dishwasher how a request is resolved depends on the status of the environment 14 7

8 Scope and Scale addressing a Thing 1. Directed, aka unicast: a sender explicitly identifies the service endpoint of the recipient - an opaque handle generated by. 2. Publish-subscribe, aka multicast: a sender publishes messages stamped with a semantic address. instances deliver to all recipients that match the address. By design, senders have no prior knowledge of the recipients, and obtain no knowledge unless (some of) the recipients reply back. 15 Semantic Address includes: The physical location of recipients as a triple of names region (e.g. "floor1" or "Pennsylvania"), area (e.g. "bedroom" or "greater Pittsburgh"), and landmark (e.g. "window" or "Point State Park"). The pipes to be traversed, which may exclude pipe traversal (local only), identify one specific pipe to traverse, or include all pipes in the dissemination environment. (note) supported interaction patterns 16 8

9 and WoT Introduces boundaries to the IoT for reasons: Social: privacy Technical: scope and scale Sphere Promotes Decentralized models with linked data Computation in local/mobile devices 17 Modeling IoT Data in a mobile world model interchange protocols are key Dragonfly Observe the user s behavior as he engages the environment External service observes the user s lighting choices (e.g., yellow lights on), and the context in which the choices occurred Penguin External service shares these observations within the network (and with U) 18 Henson 4/11/2016 9

10 Modeling user observations tailored subset of SSN for IoT Semantic Sensor Network Ontology Sensor Data Thing Observation Context Location Time 19 W3C SDW-WG Reqs ( REQ 5.18 Lightweight Model for IoT and REQ 5.20 Machine-to-Machine Henson 4/11/2016 Modeling IoT Data in a mobile world Dragonfly Receive request - service requests the profile of a user Penguin Creates a User Profile on request Filter knowledge - U decides what user knowledge is relevant for the service. Encode knowledge - U encodes the relevant knowledge into a profile and sends to the requesting service 20 Henson 4/11/

11 Modeling user profiles based on UPOS: User Profile Ontology 21 M. Sutterer, et al. UPOS: User Profile Ontology with Situation-Dependent Preferences Support 1 st Intl Conf Advances in Computer-Human Interaction, 2008 Henson 4/11/ nd quarter 2016 SDK, binaries planned binaries, SDK, docs Info DB... cloud services developer portal planned local services Party photo sharing WiPin indoor localization U Personalization Hue driver??? try out new services & use cases you may download end-users: access cloud services up/download content Dragonfly Penguin middleware open code over services / apps protocols planned 22 11