Whither User-Managed Access in the AI agent era?

Looking at both Alice-to-Bob and Alice-to-Bot sharing

This post may arrive truncated in email. Click the title to RTWT.

The User-Managed Access (UMA) protocol, whose standards effort I founded and ran for many years in the Kantara Initiative, is coming up more frequently in discussions of how to authorize service access by, and delegate access authority to, AI agents. Does UMA solve or at least illuminate important problems not covered by other elements of the stack? How ready for use is UMA, given the moment we’re in?

What is UMA again?

In November I wrote about the “non-orientability of OAuth” in a post that, along the way, explained some UMA basics. It’s been my third most popular post to date.

To restate that summary: UMA enables…

• Alice-to-Bob sharing: In the form of a somewhat creative OAuth grant spec, UMA 2.0 introduces the requesting party (RqP), an entity that serves as a counterpart to OAuth’s resource owner (RO). I used to describe it as “WAM for people” — instead of Bob simply being denied access, his client is told how and where to seek access.¹

• Ecosystem of resource protection: In a companion federated authorization spec, UMA2 introduces an API that enables loose coupling of the authorization server (AS) and resource server (RS) roles. AS:RS relationships can thus more easily become n:n, with RS’s outsourcing authorization jobs to an externalizable AS.

• Ecosystem overseen by Alice: That API is protected with OAuth itself in recursive fashion. This trust model thus puts every AS-RS pairing in an RO context, and Alice’s instructions to an AS inform the access tokens issued to those connected RS’s.

Source: Kantara UMA WG presentation

What job is UMA really trying to do here? As discussed on LinkedIn with George Fletcher, it’s going for delegation of access rights (a matter of entitlements). Think “Adding a Google Docs-like Share button to any application.”

Human-to-human sharing is the hard case. But we also ended up sketching a business/legal architecture that admits arbitrary entity-to-entity access licensing.

The UMA2 “bowtie” diagram. Source: Kantara UMA WG presentation

Either the RO or the RqP could be, for example, a corporation (non-human entity) or a baby (human not yet competent to consent) — represented through delegates that we ultimately called Resource Rights Administrators and Requesting Agents (huh, there’s that word).

Note: The protocol doesn’t explicitly address this need for delegation of authority obligations, though I’ve found it quite helpful to have names for all the actors that are floating around when building authority delegation use cases.²

What’s going on with UMA now?

I’m aware of a couple of key UMA deployments:

• Financial: The UK Pensions Dashboard Programme profiled UMA in what might be called a FAPI-like fashion to support its wide-ecosystem use case:

  Pensions dashboards will help individuals view their pensions information online, securely and all in one place, thereby supporting better planning for retirement and growing financial wellbeing.

  

  Source: Kantara UMA WG presentation

  The first pension provider connected in April and others have followed. UMA is a relatively small but critical component of this ecosystem; you can find the profiling details here.

• Healthcare and public sector: Several of Canada’s provinces have deployed UMA-based solutions developed by IDENTOS. They have extended UMA with additional privacy protections and they’ve described their solution to me this way:

  We empower our customers to offer user-centric data access and exchange, with security and privacy built-in.

  Following my tenure as UMA WG chair, IDENTOS’s CTO Alec Laws took the reins and holds them today.

Here are implementations I’m aware of, several of which are open-sourced:

• ForgeRock (now merged with Ping)

• Gluu

• HIE of One

• IDENTOS, already mentioned

• Keycloak

• Patient Centric Solutions

• Pauldron

• WSO2

While the specs have been stable since 2018 — and truth be told, there hasn’t been a lot of brand-new work on UMA-related projects — recently a vulnerability was reported and mitigated through additional security guidance (thanks, Gabriel Corona!). You can check out the details on the Kantara wiki. In a nutshell, UMA’s standardization preceded that of DPoP, so at the time we couldn’t provide exact proof-of-possession guidance, only a quick pointer to a draft in process.

What lessons does UMA hold for AI agent delegation?

Alex Simons of Microsoft posted a call-to-action on the future of AI agents in May, which provides a good starter list of requirements. Like many others, Microsoft assumes OAuth as a starting point — which is reasonable.

Similarly, the Authenticated Delegation and Authorized AI Agents paper spearheaded by the MIT Media Lab (which I pointed to in a previous post) analyzes a set of challenges posed by using the OAuth stack, including UMA.

In the interest of spurring discussion and keeping this too-long post a bit briefer, here’s a hybrid list of the challenges from both [MSFT] and [MIT] where I believe it’s useful to reflect on UMA’s capabilities and lessons learned:

The need to recognize Agent IDs as first-class actors ([MSFT] #1): UMA gives us language to talk about whether we think an agent is acting in the role of a client application or a requesting party — or maybe we need to prepare for both.³

The need to grant agents their own permissions ([MSFT] #2): UMA basically exists for this. A big motivation was solving access delegation to prepare for the day when “friendly impersonation” by sharing passwords falls over of its own weight. With passkeys and agents, it seems that day has come.

The need to track who or what an agent is acting on behalf of ([MSFT] #3): UMA’s business/legal architecture lets us talk about this more precisely, but doesn’t solve for it. I was unaware of Microsoft’s OBO OAuth profile until quite recently; we need standardized infrastructure something like this.

The need to discover permission and delegation options ([MSFT] #4): UMA doesn’t exactly address this. It has a hint of a solution in its federated authorization protection API, where the RS can make calls to a resource registration endpoint to put relevant resources and their scopes under the AS’s protection. AuthZEN is likely more suggestive given its recent work on search capabilities.

The need for more fine-grained resource- and scope-based access control ([MSFT] #5): UMA’s resource registration solution suffers from being too static given modern web resource complexity and dynamicism, so it doesn’t solve this problem.⁴ It also suffers from requiring the RS to actively make calls to the AS for admin tasks, which seems unpopular. The OAuth Protected Resource Metadata spec, recently standardized as IETF RFC 9728, addresses the latter by allowing the RS to simply declare some metadata that the AS can pick up asynchronously. But I believe this new spec still suffers from inflexibly static resource descriptors. Maybe AuthZEN could be instructive here as well.

The need to consolidate multiple sign-in flows ([MIT] #1): UMA suffers from this at a different point in the user journey than OAuth or OIDC does, because it invents a new point of centralization designed to provide human value: the UMA AS. In a wide ecosystem, the RO still has to connect each RS to the AS serving as their aggregation point. Solutions to date have leaned on the time-immemorial technique of narrowing the ecosystem to the point where AS-RS trust can be built-in. This is where [MIT] suggests using verifiable credentials to scale the experience better.

The need to mitigate server-side privacy risk ([MIT] #2): IDENTOS’s enhancements of UMA protect the AS from having to know RO-policy-related PII, and I believe the approach is wallet-like. [MIT] proposes a hybrid approach; maybe they’re right!

What do you think?

What problems do you think need solving in the AI agent era? When do you think we’ll make Alice-to-Bot delegation a “settled problem”? Where can UMA help?

Here’s a Venn diagram describing UMA’s authorization assessment guidelines so I can at least end on a pretty (geeky) picture.

Source: Kantara UMA WG presentation

1. The requesting party concept was subsequently used in IoT spec IETF RFC 9200.

2. With machine-readable privacy terms becoming a reality in IEEE P7012, the UMA licensing model may gain relevance as well.

3. The UMA WG thrashed a lot over our “party” vs. “entity” language when it specifically came to keeping our historical name of “requesting party” (lowercase) for the protocol entity representing Bob. The pair of corresponding (uppercase) legal party roles are Requesting Party (might be offline) and Requesting Agent (participates online, possibly as a delegate of the other). Whew. Maybe we also need to prepare for AI agents to get legal status and need all of these roles. Same for the resource ownership side. See also the [MIT] paper’s analysis of the need for a legal grounding for agent delegation, for which it suggests agency law.

4. The UMA WG also struggled with whether we should add a wildcarding or query language to make resource registration more realistic, but decided not to go there.