For spec authors

The specification set

The nine Internet-Drafts that specify UMA 2.0 for agents — what each covers, their identifying URIs, and how to build them.

Nine Internet-Drafts specify this profile. Three are required and together constitute it, four are optional extensions, one is a transport binding, and one specifies an agent credential.

Each document has an identifying URI. An authorization server lists the ones it implements in its uma_profiles_supported metadata, as UMA 2.0 Grant §4 asks. The AAuth document places obligations on the authorization server and is listed; the MCP binding, which governs only how a challenge travels between agent and resource, is not.

Draft Title In the set URI
core (txt) User-Managed Access (UMA) 2.0 Profile for Autonomous Agents Required https://u4a.ai/spec/core/1.0
terms (txt) Owner-Proffered Terms for UMA 2.0 Required https://u4a.ai/spec/terms/1.0
fedauthz (txt) Federated Authorization for Autonomous Agents Required https://u4a.ai/spec/fedauthz/1.0
policy (txt) Owner Policy, Assurance and Attention Optional https://u4a.ai/spec/policy/1.0
lineage (txt) Agent Lineage Optional https://u4a.ai/spec/lineage/1.0
multiparty (txt) Multi-Party Authorization Optional https://u4a.ai/spec/multiparty/1.0
owner (txt) The Resource Owner's API Optional https://u4a.ai/spec/owner/1.0
mcp (txt) Model Context Protocol Binding Binding https://u4a.ai/spec/mcp/1.0
aauth (txt) AAuth Agent Tokens as Agent Credentials Credential https://u4a.ai/spec/aauth/1.0

They are drafts, and comment on them is wanted. Open an issue on the repository, or read the findings for the recommendations behind each.

Terminology. These pages say tier where the drafts say policy unit. Same object: a group of resources with one terms document, one ask-me switch, and its rules.

What each document covers

Core — the grant. The challenge as a set of parameters rather than an HTTP header; two identity levels for the client; a proof-of-possession token carrying its permissions as a claim; operation binding and single use; the order an enforcement point runs its checks in; the standing connection; the owner's credential to her own server; and which artifacts carry an owner. Its §12 is the extension register the deviations page follows.

Owner-Proffered Terms — claims-gathering in which the authorization server proffers the claim's content. The terms document and its three representations, version immutability, the signed agreement, what the requesting side may author in it, the counter-signed receipt, and declining. Usable by any UMA deployment, agents or not.

Federated Authorization for Agents — declarative registration; discovery split into a public structural layer and a protected instance layer; resource-server establishment by a signature from the origin it serves; and the reason an introspection response gives for an inactive token.

Owner Policy, Assurance and Attention — which conditions may relax a requirement and which may only tighten, enforced when a policy is saved; three assurance axes with no composite score; a depth limit on the owner's pending queue, in two lanes; operator blocking; and what her record carries.

Agent Lineage — one agent introducing another. The introduction document and the issuer-attested alternative (AAuth's parent_agent), the six admission checks, approval pooled across a lineage, the fan-out ceiling, and the revocation cascade.

Multi-Party Authorization — Part I, an organization above the owner: its charter, the envelope clamped into her terms, roles carrying delegation, and break-glass. Part II, owners of equal standing: a published mandate, a signed verdict from each owner's authority, and a tally that carries them in the grant.

The Resource Owner's API — the surface her portal, a command line or an agent she runs uses to operate her authorization server: the queue and its decisions, her connections and the operators behind them, her resource servers, her policy and terms, the condition vocabulary, the record, and an event stream.

MCP binding — the challenge in both hosting shapes, the two discovery channels, reconciling MCP's routing headers against the body, origin validation, and truncated bodies.

AAuth agent credentials — accepting an AAuth agent token as an agent's identity: how it is verified, how the agent's connection is named from it, and how a sub-agent's parent is read from it. Nothing else of AAuth is used.

Requirements and checks

spec/conformance.yaml maps every normative statement in the set to what verifies it: a make target and the assertion that target prints, or a note that the requirement falls on a deployment or on a binding rather than on this implementation.

make spec-check fails the build if a statement has no row, a row quotes text that is no longer in the draft, a row names a make target that does not exist, or a row cites an assertion that no suite prints.

Building them

make spec

Renders spec/src/*.md through kramdown-rfc and xml2rfc in a container, into site/static/spec/. The bibliographic reference cache is committed, so the render needs no network.

What's next