UMA (User Managed Access) enhances OAuth to enable resource owners to define authorization policies for protected resources and grant access to requesting parties like clients. The UMA2 standard specifies how an authorization server can centrally manage these policies and issue access tokens to requesting parties on behalf of the resource owner. This allows resource owners to configure and monitor access without being directly involved in every authorization request. A detailed use case demonstrates how Alice can use a UMA authorization server to securely share access to her calendar with Bob so he can schedule a meeting.

1. INTRODUCTION TO UMA

2. My History with UMA
• 2009 Internet Identity Workshop session
• Person-to-person protected sharing
• Auto-updating digital photo frame
• Charter member of the working group

3. The UMA standard’s progress
3
2015 2016 2017 2018
Mar ‘15: UMA V1.0 ratified
as Recommendations
Dec ‘15:
UMA V1.0.1
ratified as
Recommendations
Jul ‘17:
1st Public Comment/
Review period ends
Sep ‘17:
2nd Public Comment/
Review period ends
Jan ‘18: Final
Recommendations
published
Specs refactored,
over 100 issues closed,
lots of implementation
input received, Disposition
of Comments doc written…
Jan ‘18:
UMA2 logo
(designed
by @domcat)
Feb ‘18:
Charter
update
Jan ‘18: Draft
UMA Business
Model Report
published
May ‘18:
Vendors
supporting
UMA2:
Gluu,
ForgeRock,
Keycloak
(WSO2
coming Q3)
Jun ‘18:
Business
model/
IRM
cxn jells

4. It has helped to kill the “password anti-pattern”
OAuth is for constrained delegation to apps
Authorizati
on server
Resource
server
Resource
owner
Client
Authorizes (consents) at run
time after authenticating, at
the AS
Standard OAuth endpoints for
authorization and access token
issuance
Some number of API
endpoints that deliver the
data or other value-add
App gets consent based on the
API scopes it requested; it has
its own identity distinct from the
RO’s
(A)
Authorization
Request
(B)
Authorization
Grant
(C)
Authorization
Grant
(D)
Access
Token
(E)
Access Token
(F)
Protected
Resource
This can come with a refresh
token for renewal without the
RO’s intervention
The RO can revoke the
token to withdraw
authorization (consent)

5. It is an OAuth-protected identity API, plus a bit more
OpenID Connect does modern-day federation
Authorizati
on server
Resource
server
Resource
owner
Client
= Federation user
= Relying party
= Identity provider
(“OpenID provider”)Standard UserInfo endpoint can be
called with an access token to look up
identity claims
Token endpoint typically delivers an “ID
token” similar to a SAML assertion

6. UX
UMA brings next-gen delegation and consent to OAuth
User-Managed Access is for cross-party sharing
Resource
server
Client
Authorizatio
n server
Resource
server
Resource
server
Requesting
party
Share Approve
Ahead of time After the fact
Monitor
Anytime
Withdraw
Anytime
Opt in
At run time
Resource
owner

7. What is User Managed Access?
• Owner definition and control of access
authorization policies for protected resources
• Access requests from arbitrary clients
• Centralized authorization policy
• Resource servers enforce policy decisions
• Binding obligations
• Profile of OAuth2

8. Why is this important?
• Next evolution beyond consent
• Consent not required at run-time
• Much richer set of policy components
• Audit and transparency
• Mutual consent between parties

9. Like OpenID Connect for identity, UMA adds an
API access management layer to OAuth2
Some use cases for UMA:
• Enterprise API protection
• For financial consumers
– Discovering and aggregating UK pension
accounts and sharing access to financial
advisors
• In industrial and consumer IoT
– For proactively or dynamically sharing smart
device control or data with others
• Healthcare
– As profiled in the Health Relationship Trust
(HEART) WG at OpenID Foundation
– Part of the new OpenMedReady framework for
trustworthy remote care
9

10. To sum up:
UMA enhances OAuth as follows
The UMA2 Grant spec
adds to OAuth2
• The resource owner authorizes protected
resource access to clients used by entities that
are in a requesting party role. This enables party-
to-party authorization, rather than authorization
of application access alone.
• The authorization server and resource server
interact with the client and requesting party in a
way that is asynchronous with respect to
resource owner interactions.
• This lets a resource owner configure an
authorization server with policy conditions at
will, rather than authorizing access token
issuance synchronously just after authenticating.
The UMA2 Federated Authorization
spec adds to the UMA2 Grant
• Multiple resource servers operating in different
domains can communicate with a single
authorization server operating in yet another
domain that acts on behalf of a resource owner.
• A service ecosystem can thus automate resource
protection, and the resource owner can monitor
and control authorization grant rules through the
authorization server over time.
• Authorization grants can increase and decrease
at the level of individual resources and scopes.
10

11. UMA V2.0 - THE PROTOCOL

12. Client requests resource
-- no RPT
-- needs_info response
-- permission ticket

13. Client redirects RqP to AS to
provide claims
-- claims interaction endpoint
-- permission ticket

14. Client requests RPT
-- extended OAuth2
-- special UMA grant
-- with client credentials

15. Client requests access to RS
-- standard OAuth2 flow
-- RPT == access token
-- from UMA grant

16. Decouple RS and AS
-- RO establishes relationship
-- standard OAuth
-- Register resources to be
protected by the AS

17. Resource registration
• Outsource authorization policy of RS endpoints to AS
• RS is final authority for releasing access
{
"name" : ”Calendar",
"icon_uri" : "http://mycals.example.com/icons/cal.png",
"scopes" : [
"http://mycals.example.com/dev/scopes/view_busy",
"http://mycals.example.com/dev/scopes/sched_normal"
],
"type" : "http://www.example.com/rsets/calendar"
}

18. The UMA2 grant of
OAuth: the basics
18
Authorizati
on server
A T
PR I
C
urn:ietf:params:oauth:grant-type:uma-ticket
D
(see also
tinyurl.com/uma2grantwsd)
TA authorization token D discovery R resource registration P permission I token introspection C claims interaction

19. Breaking apart the authorization server and resource
server (externalizing authorization)
(see also tinyurl.com/uma2fawsd)
19
Authorizati
on server
A T
PR I
CD
Resource
server
Protection
API
API
client
Resource owner of
OAuth security
over the
protection API
Producer of protection
API access token, or
“PAT”
scope = uma_protection
Protection API endpoints:
• Resource registration: Puts
resources under AS protection;
AS responds with resource IDs;
resources can have unique scopes
• Permission: Requests a
permission ticket to deliver to the
client after the tokenless resource
request
• Token introspection: Customizes
OAuth Token Introspection (RFC
7662) to enhance the token
introspection response object

20. UMA2 is not the end of our work
UMA Legal
• Exciting work on a legal
framework, a major
underlying portion of which
is just being completed
• We have been working with
legal expert Tim Reiniger,
who wrote the Virginia
digital identity law
Extensions and futures
• The Work Group has saved off a
variety of exploratory ideas for
future work in GitHub issues with
the label extension
• Examples:
– Integration points for consent
receipts
– Optimized flows that remove the
need for the permission ticket

21. Let’s Make it Real

22. Detailed use case
• Alice needs to coordinate a meeting with an
important client Bob
• Alice wants to allow Bob to view her calendar
so he can pick a time that works for both of
them
• Bob can schedule over normal calendar events
but not ones designated as high priority

23. Use Case Actors
authZ4me
(UMA AS)
scheduleMe
(cal client)
myCals
(cal srvc)
Alice
Bob

24. Alice registers protection for her calendar
authZ4me
(UMA AS)
scheduleMe
(cal client)
myCals
(cal srvc)
Alice
Bob
OAuth2
Flow
{PAT}
Register Calendar
endpoints and permissions

25. Alice UMA protects her calendar
• Standard OAuth2 flow between myCals and
authZ4me to obtain a “PAT”
• myCals registers Alice’s calendar
– https://mycals.example.com/cal/alice/work
• View, view_busy, delete, update, download, publish
• Schedule_all, schedule_normal

26. Alice defines authorization policy
authZ4me
(UMA AS)
scheduleMe
(cal client)
myCals
(cal srvc)
Alice
Bob
AuthZ Policy:
Must be Bob
Perm:
view_busy
schedule_normal

27. Alice sends Bob an email
Hi Bob,
Please view my calendar and schedule the
meeting we spoke about today.
https://mycals.example.com/cal/alice/work
Thanks,
Alice

28. Bob meets claims to access Alice’s calendar
authZ4me
(UMA AS)
scheduleMe
(cal client)
myCals
(cal srvc)
Alice
Bob
Claims negotiation
via
Permission ticket

29. Bob subscribes to Alice’s calendar
authZ4me
(UMA AS)
scheduleMe
(cal client)
myCals
(cal srvc)
Alice
Bob
Subscribe
{RPT}
Calendar View
Select Mtg
Time

30. Bob schedules a meeting with Alice
• Scheduleme POST’s to
– https://mycals/cal/alice/work/meeting
• Date, time, location
• Passes RPT in the HTTP Authorzation header

31. Meeting added to Alice’s calendar
authZ4me
(UMA AS)
scheduleMe
(cal client)
myCals
(cal srvc)
Alice
Bob
Add Mtg
{RPT}
Mtg Scheduled
Select Mtg
Time

32. Use case take-aways
• Resource and permission/scope definition very
flexible and extensible
– Resource server defined not AS defined
• Fine grained authorization across domains
• Rich set of authorization policy options
• Provides transparency for Alice as Bob walks
through the process

33. Standards
Certified device
identity
Strongly authenticated
user identity
1
2
User/device
association
3
Consented device data
sharing with others
4
Cryptographic
auditability
5
Strongly authenticated
third-party identity

34. UMA Working Group
• 2.0
– Grant (client perspective)
– Federated Authorization
• RS exporting AuthZ to AS
• Multiple implementations
• Testing suite in the works

35. Q&A
• UMA working group URL
– http://tinyurl.com/umawg
• UMA Grant for OAuth2
– https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-
08.html
• UMA Federated Authorization
– https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-
authz-2.0-08.html
• UMA Legal sub-group
– http://tinyurl.com/umalegal