Where are we today? Devices and Solutions are exploding ●  personal

o  fitness, watches, ... ●  household

o  lights, detectors, thermostats, appliances, ... ●  medical

o  heart rate monitors, ...

Emerging Pattern Each device has it’s own service in the cloud Device reports data to the service User accesses their device’s data via cloud APIs

Three examples

Internet Connected Dishwasher Big Data analytics ●  how often I wash dishes ●  when I have guests ●  when I’m not at home ●  when I’m canning

Challenges Security Ubiquity & Variety Data Model User Experience & Management

Bruce Schneider

https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html

The computers in our routers and modems are much more powerful than the PCs of the mid-1990s, and the Internet of Things will put computers into all sorts of consumer devices. The industries producing these devices are even less capable of fixing the problem than the PC and software industries were.

Security Layers

Samsung Gear Live

Types of “things” personal (fitbit) shared (family, doctor, neighbor) medical (heart monitor) industrial (air conditioner) temporary (beer glasses)

Data Model Requirements Authorization / Revocation Co-ownership Grouping / Aggregation Policy Inheritance Privacy By Design

User Experience ●  How do I allow my son to change the

thermostat but only within a limited range? ●  How do I easily add a light bulb to the family

room and have it inherit the policy already assigned to the other lights in the “family room”?

●  How do I let my friend borrow the car such that driving data is delivered to both of us?

User Experience ●  How do I sell my washing machine? (and

reset to initial state?) o  Can I save my policy from the old washing machine

and apply it to the new one? ●  How do I craft custom experiences such that

when a World Cup game comes on, the light change to my preferred team’s colors, the blinds close and the TV tunes to the correct channel?

Key Elements to Usability Simple onboarding process ●  provisioning device into personal cloud ●  grouping device with other like devices ●  pre-authorization of

o  who/what can query the device o  who/what can control the device

Key Elements to Usability Simple Authorization model ●  out-of-band user consent channel ●  alerts of abnormalities ●  sharing / multi-access ●  centralized policy management

Key Elements to Usability Simple de-provisioning ●  revocation of authorized capabilities ●  reset of device to initial state ●  removal of device from groups and

relationships ●  archive activity data for historical purposes

Building for a Better Tomorrow

Building Blocks OAuth2 OpenID Connect User Managed Access Personal Clouds

OAuth2 Basics ●  Framework for API

Authorization o  e.g. Valet Key

●  Get a token (RFC 6749) o  code, implicit,

refresh, assertion, ... ●  Use a token (RFC 6750)

o  bearer token profile

OAuth2 Dynamic Registration Client Registration Endpoint ●  Initial Access Token

o  out-of-band AuthZ ●  Software Statement

o  signed claims provided by software stack

OAuth2 Dynamic Registration flow

OpenID Connect Basics Identity layer build on top of OAuth2 ●  id_token ●  user claims ●  session management ●  logout

User Managed Access (UMA)

resource owner

resource server authorization server

client

protected resources

(unnamed till now)

UMA, Kantara Initiative: Used with Permission

UMA & Online Sharing I want to share this stuff selectively •  Among my own apps •  With family and friends •  With organizations

I want to protect this stuff from being seen by everyone in the world

UMA, Kantara Initiative: Used with Permission

I want to control access proactively, not just feel forced to consent over and over

UMA request flow Alice shares calendar with Bob ●  Alice emails Bob a link to her calendar ●  Bob goes to his calendar software and

subscribes to Alice’s calendar using the link provided by Alice in the email

OAuth2 Code Flow

UMA Request Flow

UMA 3.1.1 UMA 3.4.1 UMA 3.1.2 UMA 3.2.2 / OAuth2 Token Introspection

Personal Clouds

Slide by Phil Windley: Used with Permission

Persistent Compute Object (PICO) Identity—they represent a specific entity

Storage—they persistently encapsulate both structured and unstructured data

Open event network—they respond to events

Processing—they run applications autonomously

Event Channels—they have connections to other picos

APIs—they provide access to and access other online services

Slide by Phil Windley: Used with Permission

Picos are Decentralized & Networked

Slide by Phil Windley: Used with Permission

Picos Use an Event Query Model

Slide by Phil Windley: Used with Permission

Programming Model Program in any language you like OAuth access to pico Pico provides

user data processing API and inter-pico communications

Slide by Phil Windley: Used with Permission

Applying to IoT

Sample Use Case Adding new garage door opener to my Internet of Things - already have Car, Lights, Thermostat, etc Goal: garage door is up when I drive in the driveway

Data Model

Solution Key Components Trusted Introduction Transport Security Activity Authorization Standards Support ●  OAuth2 ●  UMA

Architectural Requirements Owner Pico functions as the UMA AS Each Pico functions as an UMA client ●  pico channel authz is RPT introspection Smart phone app functions as an UMA client Tight binding between device and device Pico

Assumptions Device manufactured with a Software Statement Device supports bi-directional NFC Device supports HTTPS User has a smart phone bound to their personal cloud (trusted app)

Software Statement JSON Signed Web Token (JWS) ●  Issuer claim [iss] (manufacturer) ●  Subject claim [sub] (device unique id) ●  JWT ID claim [jti] (unique id) ●  Device type [com.example.device.type]

Public key for signature must be retrievable via the issuer claim.

User Experience User runs personal cloud app and “taps” the Garage Door opener Garage Door opener flashes an LED to signal success Personal cloud app shows Garage Door as being connected to the House pico Personal cloud app can query (or change) the open/closed state of the door

NFC “Tap” garage door opener 1. Device transfers

software statement to phone

2. Phone transfers UMA AS endpoint to device a.  optionally network

connectivity creds

Phone app adds device to cloud

Pre-Register Device [Software_Statement]

Add Garage Door Opener to House?

Create ‘Garage Door’

Garage Door Obtains Access_Token

Register Device [Software_Statement]

Client_ID & Client_Secret OAuth2 Client Assertion Flow

Access_Token [UMA AAT]

Garage Door connects to pico

Where’s my Pico? [AAT]

Endpoint: https://… Pico ID: 123 UMA RPT Req (3.4.1)

[AAT, Pico ID]

RPT (pre-authorized) Establish Connection

[RPT]

Where are we? Garage Door device is connected to it’s pico Policy for what/who can query/control the garage door managed by the Owner pico and implemented via UMA

What do we want? Garage door to open when I drive into the driveway Assume: Car is already connected to it’s ‘Car’ pico ‘Car’ pico has a channel with the ‘House’ pico Car has geo-fence capability

Opening the Garage Door

Decommissioning the Garage Door 1.  User via their trusted app instructs the Owner pico to remove the ‘Garage

Door’ pico 2.  The Owner pico sends a message to the ‘House’ pico to delete the

‘Garage Door’ pico 3.  The ‘Garage Door’ pico can now archive any historical data before sending

a message to the ‘Garage Door’ to reset to factory defaults 4.  Owner pico revokes all ‘Garage Door’ access tokens

Benefits of this approach ●  Collected data is stored and managed under

the user’s control ●  Authorization policy across the personal IoT

cloud is centrally managed o  Lots of opportunity for innovation in how to help the

user manage their devices o  Authorization policy can be inherited across the data

model ●  Implementable today with existing standards

References UMA ●  UMA 101 2013-10-29 ●  UMA Webinar 2014-03-20 ●  UMA Core Spec

Personal Clouds: ●  Connecting Things

OAuth 2: ●  Dynamic Client Registration ●  Token Introspection

JOSE ●  JSON Web Token ●  JSON Web Signature

Questions Acknowledgements ●  UMA: Eve Maler & Domenico Catalano ●  CloudOS: Phil Windley

Appendix