Webinar: Consent 2.0: Applying User-Managed Access to the Privacy Challenge

Copyright © 2015 ForgeRock, all rights reserved.
CONSENT 2.0
APPLYING USER-MANAGED ACCESS TO THE
PRIVACY CHALLENGE
July 21, 2015

Your Hosts
Markus Weber
@MWAtForgeRock
Eve Maler
@xmlgrrl

Recent Pew Survey:
91% of American adults say that
consumers have lost control
over how personal information
is collected and used by companies.
Source: http://www.pewresearch.org/key-data-points/privacy/

Recent Accenture Survey:
67% of individuals are willing to
share data with companies
- drops to 27% if the business is
sharing data with a third party

ForgeRock’s Identity Platform
and emerging standards

ForgeRock’s Identity Platform
and emerging standards
COMMONSERVICES

aspiration
risk mitigation
cynicism

From the web
to the IoT,
the “fear/greed”
tension around data
sharing is only going
to grow

“Post-compliance” consent tools only take us so far
OAuth: standard and scoped … but
opt-in at run time, Alice-only, and closed-system
“Share”: proactive and delegable … but
proprietary, closed-system, and often insecure

Customer Identity 2.0 needs Consent 2.0
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

The new
Venn of
access
control and
consent

Financial scenario
Alice wants to allow (consent
to or delegate to) her
accountant to import her tax
data directly from her
employer’s site into the tax
return application he uses,
with the ability to revoke that
consent.

Healthcare / IoT scenario
Alice can see in her central
dashboard what resources
she already has shared.
She shared, for example,
data from her implantable
cardiac defibrillator with her
doctor.

ForgeRock’s OpenUMA solution
will help you meet
the new privacy challenge

ForgeRock is
delivering two key
OpenUMA
components by
the end of 2015
authorization
server
resource server
(client)
UMA Provider
based on
UMA Protector
based on

Additionally…
• User tab for fielding pending requests
• Resource labels for viewing and filtering
• Special “Alice-to-Alice sharing” experience

How UMA
works:
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

Where the action is at Kantara
http://tinyurl.com/umawg
Brand-new
UMA Developer Resources
Work Group

Where the action is at OpenID Foundation
HEART Profile for UMA
HEART Profile for OAuth 2.0
HEART Profile for OpenID Connect
(comes with its own SSO API)
HEART OAuth
Profile for FHIR
API
HEART UMA
Profile for FHIR
API
http://openid.net/wg/heart/

ForgeRock helps you deliver
Consent 2.0 experiences to your
customers that demonstrate context,
control, choice, and respect

RSA Conference Asia Pacific & Japan
22 - 24 July, 2015, Singapore
Gartner Catalyst Conference
10 - 13 August, 2015, San Diego, CA
Les Assises
30 September - 3 October, 2015, Monaco
Where in the World is ForgeRock?

Where to follow us:
https://twitter.com/ForgeRock
http://www.linkedin.com/company/forgerock
https://www.youtube.com/user/ForgeRock
https://vimeo.com/forgerock
http://forgerock.com/resources/

Try it & Participate!
https://forgerock.org/openuma/

THANKS! QUESTIONS?

The UMA
nitty gritty
Resource
owner
Resource
server
Authorization
server
Client
Authorization
API
UI
UI
UI
Requesting
party
Protection
API
Authorization
client
Protection
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 credentials at AS to get PAT
C needs OAuth client credentials at AS to get AAT
All protection API calls must carry PAT
All authorization 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 attempted access
4. AS returns permission ticket
5. RS returns error 403 with as_uri and
permission ticket
6. C requests authz data, providing permission
ticket
7. (After 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

Webinar: Consent 2.0: Applying User-Managed Access to the Privacy Challenge

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Webinar: Consent 2.0: Applying User-Managed Access to the Privacy Challenge

Similar to Webinar: Consent 2.0: Applying User-Managed Access to the Privacy Challenge (20)

More from ForgeRock

More from ForgeRock (20)

Recently uploaded

Recently uploaded (20)

Webinar: Consent 2.0: Applying User-Managed Access to the Privacy Challenge

Editor's Notes