Devices need owners, people need confidence in device authenticity, data needs to persist in systems long after devices change hands, and access needs to be authorized selectively. That's a lot to ask; even if emerging web identity and security technologies are simpler than the models of yesteryear, IoT devices have complicating limitations when it comes to processing power, memory, user interface, and connectivity. But many use cases span web and IoT environments, so we must try! What are the specific requirements? What elements of web technologies can we borrow outright? What elements may need tweaking?

1. IDENTITY RELATIONSHIP
MANAGEMENT IN THE
INTERNET OF THINGS
TRIANGULATING PEOPLE, DEVICES, AND SERVICES
Eve Maler | @xmlgrrl | eve.maler@forgerock.com
10 June 2015

2. From the web
to the IoT,
the “fear/greed”
tension around
data sharing is
growing

3. If privacy isn’t secrecy, what does IRM need
to make selective data sharing viable?
Context The right moment to make the decision to share
Control The ability to share just the right amount
Choice The true ability to say no and to change one’s mind
Respect Regard for one’s wishes and preferences

4. Existing consent tools, are good, but…
OAuth: standard and scoped…but opt-in,
point-to-point, and single-party
“Share”: proactive and party-to-party…but
proprietary, point-to-point, and often insecure

5. The new
Venn of
access
control and
consent

6. Organizations need UMA to deliver selective
sharing in IoT environments

7. The
mechanism:
federated
authorization
on top of
OAuth
Loosely coupled to enable
centralized authorization-as-
a-service for any number of
an individual’s resource
servers
A new concept, to enable
party-to-party sharing
driven by policy (or access
approval) rather than
requiring the individual to
be present at access time
Authorization data is added to this token
if trust in the requesting party is
successfully elevated, typically through
authentication and/or claims-gathering

8. Let’s see it in action with a
connected-car scenario

9. What just
happened?
Resource
owner
Resource
server
Authoriza0on
server
Client
Authoriza0on
API
UI
UI
UI
Reques,ng
party
Protec0on
API
Authoriza*on
client
Protec*on
client
RS-­‐specific
API
RS-­‐specific
client
2
1
5
RPT
6
7
8
3
4
PAT
11
AAT
PAT
PAT
RPT
chooses
resources
to
protect
–
out
of
band
sets
policies
–
out
of
band
AAT
9
10
PAT
RS
needs
OAuth
client
creden,als
at
AS
to
get
PAT
C
needs
OAuth
client
creden,als
at
AS
to
get
AAT
All
protec,on
API
calls
must
carry
PAT
All
authoriza,on
API
calls
must
carry
AAT
1. RS
registers
resource
sets
and
scopes
(ongoing
–
CRUD
API
calls)
2. C
requests
resource
(provisioned
out
of
band;
must
be
unique
to
RO)
3. RS
registers
permission
(resource
set
and
scope)
for
aQempted
access
4. AS
returns
permission
0cket
5. RS
returns
error
403
with
as_uri
and
permission
0cket
6. C
requests
authz
data,
providing
permission
0cket
7. (AVer
claims-­‐gathering
flows
not
shown)
AS
gives
RPT
and
authz
data
8. C
requests
resource
with
RPT
9. RS
introspects
RPT
at
AS
(default
profile)
10. AS
returns
token
status
11. RS
returns
20x
UProtect
DriveSafe,
then
AllForYourCar
DriveSafe
Hans
Alice

10. Taking this “webby” approach to IoT sharing
relationships requires careful attention
A deeper “systems design” view of
vulnerabilities is required – e.g….
Authentication and linkages have new
constraints – but also new options
logical physical
Access control must
fail closed
Life and limb is at risk
if access control fails
closed
Usually the “constrained
entity” (if there is one); often
a device paired to a service
and gateway
Is a connection
available at access
attempt time? What
to do if not?

11. THANKS!
Eve Maler (@xmlgrrl)

12. THANKS!
Eve Maler | @xmlgrrl | eve.maler@forgerock.com
10 June 2015