Authorization Notes No. 5
Imagine that you ask a contractor to collect a piece of equipment from a warehouse operated by another company. The contractor may be able to show who they are, but the person at the warehouse still needs to know who sent them, which equipment they may collect, whether they may send someone else in their place, and whether the permission is still valid.
There are several ways the two companies could answer those questions. They might arrange a phone call between managers. They might rely on a shared identity system. They might issue a signed collection order. They might give the contractor a temporary credential that works only at that warehouse and only for that equipment. The mechanisms differ, but the questions do not.
That is what I think we are beginning to see in agent authorization. Over the past several months, and especially over the past several weeks, a number of Internet-Drafts have started describing fine-grained authorization, human consent, agent identity, delegation chains, cross-organizational trust, revocation, and evidence that can accompany an action.
These documents are proposals. An Internet-Draft can be submitted by an individual, can change substantially, and may never become a standard. Most of these drafts have not been adopted by an IETF working group, and none should be read as settled IETF consensus. Some are problem statements. Some combine existing OAuth mechanisms. Others define new authorization objects or protocols. What matters is that they are increasingly arriving at the same boundary. The problem definition is converging faster than the architecture.
Digital workers are reaching the point of consequence
This week, Reuters reported that India is preparing an agentic-payments rollout for its Unified Payments Interface. The report is an important sign of where digital workers are heading. They are moving from finding information and preparing actions toward initiating transactions in systems where mistakes have immediate consequences.
A payment system cannot stop at asking whether a digital worker authenticated successfully. It needs to know whether a person authorized this payment, for this recipient, within this amount and time period. If one digital worker asks another to complete the transaction, the system also needs to know whether delegation was allowed and whether the second worker received the same authority or a narrower part of it.
The same questions appear when a digital worker places an order, changes a cloud environment, accesses a health record, writes to a repository, or directs a machine. The receiving system is not being asked to trust an interesting answer. It is being asked to permit an action.
This is why the standards activity feels urgent. The authorization problem is no longer waiting for digital workers to become capable enough to act. The systems around them are being designed now.
One proposal now states the cross-company problem directly
On August 31, a new revision of an Internet-Draft titled Cross-Organizational Delegation for Workload and Agent Identity: Problem Statement and Requirements was published in the WIMSE context.
The draft is deliberately mechanism-neutral. It does not propose a protocol. Instead, it describes the problem that appears when software acts for a human principal, delegates work recursively, and crosses between independently administered organizations.
Its requirements are revealing. A receiving organization should be able to understand the original principal, the delegation path, the authority remaining at each hop, the resource and action being requested, and the freshness or revocation state of the authorization. It should be possible to verify authority without depending on a callback to a runtime controlled by the sender. The evidence should remain useful for audit across domains, while sensitive information should not be disclosed unnecessarily.
That is a meaningful development because it separates agreement about the problem from agreement about the solution. It says, in effect, that ordinary workload identity and token mechanisms do not yet give independently operated systems everything they need for recursive, cross-organizational delegation.
The boundary it identifies is real: one organization’s internal authorization decision is not automatically verifiable authority for another organization.
Several architectures are forming around that boundary
The proposed solutions do not all make the same choices. The AI Agent Authorization Integration Framework assembles a broad set of OAuth-related work. Its model includes agent authentication, cross-domain identity, user interaction and consent, policy, authorization evidence, and chain delegation. The resource server validates the token and evaluates policy before performing or refusing the operation. This is an integration architecture: it shows how several mechanisms could work together as one authorization system.
The Credential Delegation Protocol for AI Agents in Multi-System Environments takes another composition approach. It combines OAuth Token Exchange, proof-of-possession, Rich Authorization Requests, and CIBA-derived user consent. It proposes scoped and attenuated delegation tokens, delegation-chain integrity, credential wrapping, revocation propagation, and an audit chain for agents working across service providers.
The latest revision of the OAuth Profile for Delegated AI Agent Authorization is narrower. It intentionally uses existing OAuth and JOSE mechanisms, defines no new JWT claims or OAuth endpoints, and leaves policy engines, audit stores, budgets, event streams, and credential vaults outside its interoperable core. It focuses on authenticated human consent, resource-bound and sender-constrained access tokens, attenuated delegation through OAuth Token Exchange, and safe refresh-token rotation.
The OpenA2A Agent Authorization Protocol proposes a more expansive token model. It defines an agent identity token, a capability grant token, a delegation assertion, behavioral attestation, cross-organizational federation, and revocation propagation. It presents itself as an authorization complement to agent communication protocols such as A2A and MCP.
The differences are the point. We are not watching a finished standard emerge. We are watching the design space become visible. What I find significant is not that these proposals agree. It is that they now disagree inside a much more clearly defined problem.
The questions underneath the proposals are remarkably consistent
Despite their architectural differences, the drafts keep returning to a common set of questions. Who is the digital worker acting for, and what did that principal actually approve? Which action, resource, purpose, amount, and time period does the authority cover? Can the worker delegate, and must every later delegation become narrower? How is the authority bound to the worker presenting it and to the request being made?
They also ask what the receiving system can establish for itself. Can it verify the chain without joining the issuer’s internal control plane? What happens when authority expires, is revoked, or reaches a different organization? Which facts should travel with the work, and which decisions should remain local to the receiver? Together, these questions describe an authorization layer: not one product category or one protocol, but a set of responsibilities that the rest of the agentic stack cannot safely absorb by accident.
Identity cannot answer all of them. A communication protocol cannot answer all of them. A policy engine can decide what its own organization should allow, but that decision does not automatically become evidence another organization can evaluate. An audit record may explain what happened after the fact, but it cannot stop an unauthorized action unless it reaches the enforcement point before the action occurs.
These systems complement one another, but none of them should be expected to silently carry the full meaning of authority.
Policy and proof remain different jobs
The emerging work also makes one distinction increasingly important. Policy determines what should be allowed. Proof gives another system evidence of what was authorized.
An enterprise may use OAuth, IAM, Rego, OPA, Cedar, risk signals, approval workflows, or a combination of them to decide whether authority should be granted. Those systems can depend on private information and local rules that should never leave the organization.
When the work crosses a trust boundary, the receiver does not necessarily need the issuer’s entire policy environment. It needs enough evidence to determine who granted the authority, what it covers, how it changed through delegation, whether it is still valid, and whether it belongs to the request and presenter now at the boundary.
The receiver then applies its own policy. Valid authority does not compel a bank to transfer money, a supplier to accept an order, or a machine to execute a command. It gives the receiving system a verifiable input to its own decision.
This is the distinction we are exploring with Ratify Protocol. Ratify represents delegated authority as signed, constrained, and revocable evidence that can travel across digital workers and systems. A receiver can verify the delegation chain and the authority that arrived without calling or trusting Ratify infrastructure.
That does not make Ratify a replacement for OAuth, identity, policy engines, gateways, sandboxes, communication protocols, or local enforcement. Those systems still decide how authority is issued, control credentials, carry requests, apply local rules, and make the final action succeed or fail. Ratify is focused on the portable part of the problem: what authority actually arrived, and can the receiver verify it for itself?
This is the moment to test the assumptions
Standards work often looks slow from the outside. Then terminology, data models, and trust assumptions begin to settle, and choices that once looked provisional become expensive to change. Before the industry converges on a mechanism, we need to test what happens when authority crosses a real company boundary. We need to know whether delegation remains narrower across several hops, whether revocation reaches the final receiver in time, whether proof can be verified without exposing private policy, whether the authorization is bound to the action that occurs, and whether two independently built implementations reach the same result.
We also need to test where portability should stop. A receiver should not surrender its own policy. A signed delegation should not become a command. Human consent should not become a ceremonial screen that approves an authority the person cannot understand. Adding more claims to a token should not be mistaken for proving that the action itself was authorized.
The proposals appearing now will not all survive in their current form. Internet-Drafts are working documents, and disagreement is part of how the architecture improves.
But the repeated appearance of delegation, attenuation, consent, cross-domain verification, revocation, and authorization evidence is a signal. Digital workers are exposing a missing layer between identity and action, and several authors and standards communities are now trying to describe it.
The category is crystallizing because the same questions now appear across proposals with very different answers. The problem definition is converging faster than the architecture, which makes this the time to decide what the authorization layer must prove before its assumptions harden into infrastructure.