]> MindGarden LLC

nickgamb@gmail.com

Venn Factory

Security UMA authorization MCP Model Context Protocol agents binding This document binds the UMA 2.0 profile for autonomous agents to the Model Context Protocol. It specifies how a resource offering MCP tools emits the authorization challenge, in the two shapes an enforcement point may take; how a client discovers before its first call that it must negotiate a grant and where; and what an enforcement point that routes on MCP's request headers must do to avoid being steered by them. The negotiation itself is not MCP. The challenge and the eventual call ride MCP; the grant is obtained over HTTP from the owner's authorization server exactly as in the core profile, which is what lets the same grant serve other bindings unchanged.

Introduction is the protocol autonomous agents call tools over, and its 2026-07-28 revision requires a protected MCP server to publish protected resource metadata and to challenge with it. That is most of what needs from a transport. What MCP does not have is a second principal: a party who is not the client's own user, is not present, and whose policy decides. This binding adds nothing to MCP. It says how the parameters of Section 3.1 travel over it, in each of the two places an enforcement point may sit, and it names one hazard in MCP's routing headers that any enforcement point reading them must handle.

Relationship to the Set This document is one binding of . Others are possible; a binding to the challenge header of is the obvious second, and Section 1.2 names a third. Its identifying URI is https://u4a.ai/spec/mcp/1.0.

Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Discovery A client MAY learn that a resource requires a grant under this profile, and from which authorization server, through any of three channels. A resource MUST offer the first and MAY offer the others, and all MUST be generated from one registry of the resource's tools.

Protected resource metadata:

As and Section 2.1, which already requires. Fetched, not negotiated.

Alternative metadata encodings:

The same structural facts under another convention, such as the resource metadata of .

Capability advertisement:

A resource enforcing in-process MAY advertise this profile in the capabilities.extensions member of its handshake response under the identifier dev.uma4agents/uma-enforcement, carrying the grant type, the authorization servers, and the JSON-RPC error code of .

The third channel is the only one that is negotiated rather than fetched: it arrives in the handshake the client was already doing, with no extra round trip and no well-known URI. A client that receives it knows, before its first tool call, that it must negotiate a grant and where. Whichever channel a client learns from, it MUST corroborate the authorization server named in any later challenge against the metadata document as Section 3.4.

The Challenge Only tool invocation is protected. An enforcement point MUST allow session bootstrap and discovery methods without authorization, and MUST refuse, by default, any method it does not recognise as either open or protected. Deny-by-default matters here more than usual: one revision of added several method families at once, and an allow-list written against the previous revision would have let each of them through. The parameters of the challenge are those of Section 3.1. How they travel depends on whether the enforcement point has an HTTP status line to decorate.

At a Gateway An enforcement point in front of the resource, answering at the HTTP layer, MUST use the HTTP binding of Section 3.2: 401 Unauthorized with WWW-Authenticate: UMA. The JSON-RPC body of the refused request is not answered; the client never reached the resource. An enforcement point hosted as an external authorization service of a gateway can answer a refusal with a body and a status, and can answer an allow with nothing the client will see. It therefore MUST NOT attempt to answer a challenge as a JSON-RPC result; a pending grant cannot be expressed from that position, and the challenge is an error in both encodings for this reason.

In Process An enforcement point inside the resource — an MCP server that applies this profile to itself — has no status line. It MUST answer a tools/call it refuses for want of authorization with a JSON-RPC error whose code is -32001, and whose data member is an object carrying every parameter of Section 3.1 under its own name:

authorization_remediation is carried as the object itself rather than base64url-encoded, since JSON-RPC carries JSON. Its content MUST be identical to what the HTTP binding would have encoded. That the same object rides both envelopes byte for byte is what shows the remediation payload of is portable, and only the envelope is binding-specific. A refusal for any other reason MUST use code -32002, with data carrying error and status as the HTTP binding would have.

A Client Reads Both A client implementing this binding MUST recognise both encodings and MUST negotiate identically after either. The reference implementation's requesting agent does, and the two hosting shapes run against one authorization server.

The Negotiation and the Call The negotiation of Section 4 is carried over HTTP with the owner's authorization server and is not MCP. This is deliberate: MCP carries the challenge and the eventual call, and nothing about the grant depends on it. The eventual call is the original tools/call, re-sent with the requesting party token in an Authorization header with the PoP scheme and signed as Section 6. Where the enforcement point is in process, the signature components are the HTTP request that carried the JSON-RPC message.

Waiting When the owner has been asked and has not answered, a requesting side that can render a wait SHOULD hand it up as an input-required result carrying a resumable request state, as defines, rather than hold the call open. The requesting side MUST NOT attempt to satisfy that wait from its own user. 's input-required result addresses the client's own model, filesystem or human, and has no member for a principal who is not on this connection. Until it does, an implementation MUST convey in the human-readable content of the request that the party being waited on is the resource owner and is not reachable by the client, and MUST limit what it asks its own user to the one question that is genuinely theirs: keep waiting, or stop.

Routing Headers 2026-07-28 requires Mcp-Method and Mcp-Name request headers so that an intermediary can route and decide without parsing the body. They also let an intermediary be steered. A header naming an open method over a body naming a protected one is two parsers disagreeing about one message, which is the request-smuggling shape arriving in a new protocol. An enforcement point that reads these headers MUST reconcile each against the body and MUST refuse a request on which they disagree. On protocol version 2026-07-28 and later it MUST require both headers on protected methods rather than checking them only when present; an absent header is as steerable as a lying one.

Origin An enforcement point MUST validate the Origin header of a request against the origins it is configured to serve, where one is present, and MUST refuse a request from an origin it does not serve.

Truncated Bodies Where an enforcement point is hosted behind a gateway that forwards a bounded prefix of the request body, it MUST detect that the body it received was truncated and MUST refuse with a reason naming the truncation, as Section 12.7. A truncated JSON-RPC body does not parse, the method disappears, and deny-by-default catches it under the wrong name.

Security Considerations The considerations of apply. The following are specific to this binding.

Two Parsers, One Message See . Every header that lets an intermediary skip parsing the body is a header that lets an attacker tell the intermediary one thing and the resource another.

The Challenge Is an Error See . A gateway-hosted enforcement point cannot return a result the client will see, so a design that expresses a pending grant as a result from that position cannot be implemented. Both encodings use an error so that a client need not care which host it reached.

Deny by Default Is Not Optional See . The method surface of grows between revisions, and an enforcement point that enumerates what to refuse rather than what to allow will be wrong after the next one.

Privacy Considerations The considerations of apply. The capability advertisement of discloses the owner's authorization server to any client that completes a handshake, which the protected resource metadata already discloses to anyone who fetches it. No additional disclosure is made.

IANA Considerations This document makes no request of IANA. The JSON-RPC error codes -32001 and -32002 are in the range reserves for implementation-defined server errors, and the extension identifier dev.uma4agents/uma-enforcement follows 's convention for vendor-prefixed extension identifiers.

This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. Model Context Protocol project JSON-RPC Working Group In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Hellō This document defines the AAuth authorization protocol for agent-to- resource authorization and identity claim retrieval. The protocol supports four resource access modes — identity-based, resource- managed (two-party), PS-managed (three-party), and federated (four- party) — with agent governance as an orthogonal layer. It builds on the HTTP Signature Keys specification ([I-D.hardt-httpbis-signature-key]) for HTTP Message Signatures and key discovery. Raiffeisen Bank International OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] standardizes the exchange and processing of authorization details but does not define metadata for describing authorization details types. In addition, no interoperable guidance is offered to clients, to remediate failures by resource servers due to insufficient authorization details. This document addresses this interoperability challenge, allowing clients to dynamically discover metadata instead of relying on out- of-band agreements, as well as standardizes failure signaling including interoperable remediation when insufficient authorization details are the cause of failure. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Implementation Status This section records the status of known implementations in the sense of , and is to be removed before publication as an RFC. The reference implementation runs both hosting shapes of against one authorization server — an external authorization service ahead of an unmodified MCP server, and an MCP server extension applying the profile in process — and one requesting agent negotiates through either. The routing-header hazard of was found by sending the mismatched pair and watching a header-trusting enforcement point wave it through; the reference MCP SDK independently rejects the same pair. The truncation of was found by sending a body one byte over a gateway's limit and reading the refusal it produced.

Acknowledgments 's 2026-07-28 revision arrived, from a different direction, at most of the shapes this profile needs: an opaque server-minted state that the client echoes back, a result that means waiting rather than failure, and a polling interval. Two designs reaching the same shapes eight years apart suggests the shapes are forced.