digital consent: taking uma from concept to reality
TRANSCRIPT
DIGITAL CONSENTTAKING UMA FROM CONCEPT TO REALITY
Eve Maler (@xmlgrrl)
The personal data gathering dark ages
Web 1.0 Web 2.0
Copyright © Identity Summit 2015, all rights reserved.
Privacy goals vs. reality
aspirationrisk mitigation
cynicism
Copyright © Identity Summit 2015, all rights reserved.
From the webto the IoT,
the “fear/greed” tension around data sharing is only going to
grow
Copyright © Identity Summit 2015, all rights reserved.
“Post-compliance” consent toolsonly take us so far
OAuth: standard and scoped…but opt-in, app-to-app, and point-to-point
“Share”: proactive and party-to-party…but proprietary, point-to-point, and often insecure
Copyright © Identity Summit 2015, all rights reserved.
Customers with identities in the digital worldneed Consent 2.0 solutions
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
Copyright © Identity Summit 2015, all rights reserved.
The new Venn of access
control and consent
Copyright © Identity Summit 2015, all rights reserved.
Copyright © Identity Summit 2015, all rights reserved.
Businesses and governments need the UMA standard to deliver Consent 2.0 successfully
Copyright © Identity Summit 2015, all rights reserved.
The mechanism:
federated authorization
on top of OAuth
Loosely coupled to enablecentralized 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
Copyright © Identity Summit 2015, all rights reserved.
Let’s see it in action with OpenUMA
Copyright © Identity Summit 2015, all rights reserved.
What just happened?
Resource owner
Resource server
Authorization server
Client
Authorization API
UI
UI
UI
Requesting party
ProtectionAPI
Authorization client
Protectionclient
RS-specificAPI
RS-specific client
2
1
5RPT
6
7
8
3
4
PAT
11
AAT
PAT
PAT
RPT
chooses resources toprotect – out of band
sets policies –out of band
AAT
9
10
PAT
RS needs OAuth client credentials at AS to get PATC needs OAuth client credentials at AS to get AATAll protection API calls must carry PATAll 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 ticket5. RS returns error 403 with as_uri and
permission ticket6. C requests authz data, providing permission
ticket7. (After claims-gathering flows not shown) AS
gives RPT and authz data8. C requests resource with RPT9. RS introspects RPT at AS (default profile)10. AS returns token status11. RS returns 20x
UProtect
First BHealthy, then
HappyHeart
BHealthy
Copyright © Identity Summit 2015, all rights reserved.
ForgeRock is delivering two key
OpenUMAcomponents by the
end of 2015
authorization server
resource server
(client)
UMA Providerbased on
UMA Protectorbased on
Copyright © Identity Summit 2015, all rights reserved.
THANKS!
Eve Maler (@xmlgrrl)