Use – Managed Access (UMA) – 101 Session

From IIW

User-Managed Access (UMA) – 101 Session

Tuesday 3B

Convener: Eve Maler, Kantara Initiative UMA Workgroup Chair

Notes-taker(s): Thomas Berry & Eve Maler

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

1. Notes Received from Thomas Berry:

User-Managed Access (UMA) 101

  • OAuth enables constrained delegation of access to apps
    • Alice to Apps by way of authorization server and resource server (A-T-D) Authorization, Token, Directory
    • Benefits:
      • Flexible, clever API security framework
      • Alice can agree to app connections and also revoke them
  • OpenID Connect does modern-day federation
    • Benefits
      • Layers identity/authentication tech with delegation/authorization tech
      • Translates federated identity for mobile and the API economy
    • Federation user, relaying party, identity provider (standard UserInfo endpoint)
  • With other problems exist
    • To OAuth, UMA adds cross-party sharing
    • Alice (resource owner) needs to share with Bob (requesting party) [by way of client]
    • By way of Authorization server (A and T) and Resource server
  • Benefits
    • Secure delegation
    • Alice can be absent when Bob attempts access
    • Helpful error handling for client applications
    • Alice controls trust between a service that hosts her resources and a service that authorizes access to them

Authorization server :A T D R P I C

  • Aggregation is not a solution: resource server exists in many Ns
    • A Authorization
    • T Token
    • D Discovery
    • R Resource integration
    • P Permission
    • I Token Introspection
    • C Claims Interaction
  • Imagine what delegation means to an autonomous third-party

UMA Experience Opportunities

UX (consent):

Share Button (ahead of time)

Opt-In (At run time)

Approve (After the fact)

Monitor (Anytime)

Withdraw (Anytime) - revoke

Benefits for service providers: a summary

  • True secure delegation; no password sharing
  • Scale permission-ing through self-service
  • API-first protection strategy
  • Foster compliance through standards

Benefits for individuals

  • Choice in sharing with other parties
  • Convenient sharing/approval with no outside influence
  • Centralized monitoring and management
  • Control of who/what/how at a fine grain

Typical use cases

  • Alice to Bob (person to person)
  • Discovering/aggregating pension accounts and sharing access to financial advisors
  • Connected car data and car sharing
  • Enterprise to Alice (initial RO is an organization)
    • Enterprise API access management
    • Access delegation between employees
  • Alice to Alice (person to self/app)
    • Proactive policy-based control of app connections

Profiled or referenced by:

  • OpenID Foundation HEART Working Group (HEalth Relationship TRust)
  • UK Department of Work and Pensions
  • OpenMedReady Alliance

Forge Rock



HIE of One/Trustee



RedHat SSO (Keycloak)


UMA in a nutshell

  • developed at Kantara Initiative
    • V1 done in 2015
  • Leverages existing open standards
    • OAuth and OpenID Connect and SAML (optional but popular)
  • Specs contributed to IETF OAuth WG in Feb
  • Profiled by multiple industry sectors
    • Financial, Healthcard
  • UMA business model effort supports legal licensing for personal digital assets
    • Mother (guardian) manages sharing for child (data subject); child “ages in” to consent and starts to manage sharing herself
  • Some 1:1 interop testing done; more soon?


  • Patient Alice creates a policy to share with Dr. Erica; Alice selects her sharing preference and presses SHARE.
  • Patient sharing is easy!

ForgeRock Identity Platform

  • profile and privacy management dashboard — also access management module
  • Rock ‘N’ Roll Supermarket demonstration
    • Sharing (shared resources)
    • Activity (account actions/history)

The marvelous spiral of delegated sharing, squared

  1. UMA grant of OAuth enables Alice-to-Bob 
  2. UMA standardized an API for federated authorization at the AS to make it centralized
  3. There are nicknames for enhanced and new tokens to keep them straight

RFC 6749

UMA extension grant adds

  • party-to-party: resource owner authorizes protected-resource access to clients used by requesting parties
  • asynchronous: resource owner interactions are async with respect to the authorization grant
  • Policies: resource owner can configure an AS with rules (policy conditions) for the grant of access, vs. just authorize/deny
    • Such configurations are outside UMA’s scope

Resource owner | Client + Requesting party


UMA federated authorization adds

  • 1-to-n: multiple RS’s in different domains can use an AS in another domain
    • “Protection API” automates resource protection
    • Enables resource owner to monitor and control grant rules from one place
  • Scope-grained control: Grants can increase/decrease by resource and scope
  • Resources and scopes: RS registers resource details at the AS to manage their protection

Promises BLT business-legal-technical

UMA grant details

swim-lanes slide

Client’s first resource request is tokenless: this exists in WAM

  • response includes a permission ticket to continue (allows AS discovery)
  • Claims-based access control in the form of claims collection options
  • Assessment and token issuance as guardrails
  • RPTs upgraded, revocation, ...

The permission ticket: how you start building a bridge of trust

  • Binds client, RS, and AS: Every entity may be loosely coupled; the whole flow needs to be bound
  • Refreshed for security: The client can retry RPT requests after non-fatal...

Pushed claims scenario is the most common implementation; for wide-ish ecosystems

  • AS is requesting party’s IdP and the client is the RP
  • RS’s initial response to the client
  • Client pushes its existing ID token to the token endpoint
  • AS is in the primary audience for this token
  • Somewhat resembles SSO or the OAuth assertion grant, where a token of expected type and contents is “turned on”

Really wide ecosystems

  • (Details already seen)
  • Claims interaction endpoint must have been declared in the discovery document to allow this flow
  • The AS mediates gathering of claims from any source
  • A key “metaclaim” to think about: consent to persist claims; kind of like a refresh token opportunity (persistent claims token [PCT])
  • Resembles the authorization code grant, but can apply to non-unique identities and is repeatable and “buildable” (a model for cross party interaction)

Federated authorization

  • RS registers resources: This is required for an AS to be “on the job”
  • RS chooses permissions: the RS interprets the client’s tokenless resource request and requests permissions from the AS
  • RS can introspect the RPT: UMA enhances the token introspection response object
  • RO controls AS-RS trust: the protection API is OAuth-protected

UMA features

  • Registering a resources puts it under protection
  • Deregistering removes it from protection
  • While registered, configuration changes can be made

Resource and scope registration

  • The RS is authoritative for what its resource boundaries are
    • It registers them as JSON-based descriptions
    • There is a resource...
  • Scopes can be simple strings or URIs that point to description documents

Permission endpoint

  • RS interprets the clients tokenless (or insufficient-token)
  • RS ...


Relevance for privacy beyond “empowered flows”

  • features relevant to privacy regulations
  • Work on well along on an ...

(Most) legal relationships in the business model

******************** ********************* ******************** ********************

2. Notes Received from Eve Maler:

Here is the bullet list of topics:

• Overview

• UMA in action

• The technical big picture

• The UMA grant

• Federated authorization

• Authorization assessment

• Privacy and business-legal-technical implications

 Direct link to slide deck: