The Challenge
The OpenID Foundation's AuthZEN Working Group tackled a key interoperability issue: AuthZEN offers a standardized API for authorization decisions, but each protocol and system uses different authorization parameters. Your REST API might use HTTP headers and path parameters, while your GraphQL endpoint relies on operation names and variables. Meanwhile, your Model Context Protocol (MCP) server uses JSON-RPC method calls with tool-specific arguments.
Without a standardized translation layer, teams create custom middleware for each system. This duplicates security logic, applies policies inconsistently, and causes authorization decisions to diverge across the technology stack. The problem worsens with AI agents, which can introduce the confused deputy problem: an agent authorized to act for a user might access tools beyond the user's permissions.
The working group needed a solution that works across protocols and addresses AI agent authorization challenges.
The Environment and Constraints
The AuthZEN Authorization API uses the Subject-Action-Resource-Context (SARC) model. A Policy Enforcement Point (PEP) sends a structured request to a Policy Decision Point (PDP), which returns an allow or deny decision. This works well when you control both sides of the interaction.
Problems arise when securing systems you don't control, third-party APIs, emerging protocols like MCP, or legacy interfaces with fixed models. Each operation carries authorization data in different formats: OAuth tokens in headers, customer IDs in path parameters, tool names in JSON-RPC method fields.
For MCP, constraints are tighter. AI agents act for users through Delegated Authorization. A single MCP tool call might include the agent's identity, the user's identity, operation-specific parameters (like a customer ID), and contextual metadata (like a case number). The authorization decision needs all these inputs, but MCP's JSON-RPC structure doesn't map directly to AuthZEN's SARC model.
The working group also considered deployment realities: some teams run MCP servers directly, while others use centralized MCP gateways managed by IT security. The solution needed to support both without forcing architectural changes.
The Approach Taken
The working group released two draft specifications: the COAZ Framework and the COAZ-MCP Binding.
COAZ (Compatible with OpenID AuthZEN) offers a protocol-neutral pattern for mapping any system's information model into AuthZEN authorization requests. Instead of custom translation logic for each protocol, you define a declarative mapping using the Common Expression Language (CEL). The mapping extracts values from the incoming operation and projects them into the SARC structure.
For example, a mapping might extract the user ID from $token.sub, the operation name from $tool.name, the customer ID from $params.customerId, and the agent ID from $token.client_id. The PEP evaluates these expressions against the request and constructs the AuthZEN call dynamically.
COAZ-MCP applies this framework to MCP's JSON-RPC message structure. It defines default mappings for each MCP method, ensuring basic authorization without per-operation configuration. Tools can override these defaults by declaring custom COAZ mappings in their input schemas.
This approach separates three concerns: business logic (declaring relevant authorization parameters), policy enforcement (evaluating the mapping and calling AuthZEN), and policy decision (centralized in the PDP). An MCP gateway can enforce the binding without the downstream server knowing, or the server can handle it directly if no gateway exists.
Results and Metrics
The drafts are open for review on the OpenID AuthZEN GitHub repository. The working group seeks feedback from identity professionals, security architects, and developers before advancing to Implementer's Draft status.
The technical approach addresses core problems. COAZ removes the need for protocol-specific middleware by providing a single declarative pattern. COAZ-MCP solves the confused deputy problem by ensuring every JSON-RPC message is authorized before execution, handling both user and agent identities explicitly.
Separating enforcement from business logic also offers a practical deployment path. IT teams can deploy MCP gateways that enforce centralized authorization policies while application teams declare their tool-specific mappings independently.
What They Would Do Differently
The current drafts are a starting point, not a finished standard. The working group is asking: Does COAZ meet your needs? What's missing? What's inconsistent?
One area under discussion is the choice of CEL as the default expression language. While CEL suits this use case, some implementers may prefer alternatives. The framework is designed to be expression-language-agnostic, but the default choice impacts interoperability.
Another question is handling complex authorization scenarios requiring multiple PDP calls or stateful evaluation. The current COAZ model assumes a single synchronous authorization request per operation. Real-world systems sometimes need more sophisticated patterns, like conditional evaluation or multi-stage approval.
The working group is also gathering feedback on MCP-specific defaults. Are the default mappings suitable for most tools, or do too many cases require custom overrides?
Takeaways for Your Team
If you're securing APIs or protocols with externalized authorization, COAZ provides a reusable pattern. Instead of custom translation logic for each system, define a mapping once and let the PEP handle the rest. This is crucial when running multiple protocols against the same PDP, consistent translation means consistent policy enforcement.
For teams deploying AI agents through MCP, COAZ-MCP addresses a real security gap. Without standardized authorization at the tool invocation level, you're relying on coarse-grained access decisions that don't account for specific operations, resources, or contexts. The confused deputy problem isn't theoretical, it's the default outcome when agents act on behalf of users without fine-grained authorization.
The practical deployment path is through MCP gateways. If your IT security team controls a centralized gateway, they can enforce COAZ-MCP bindings without requiring changes to downstream MCP servers. The servers declare their mappings; the gateway enforces them.
These are drafts. Review them. Test them against your authorization requirements. If something doesn't fit your environment, file an issue on the AuthZEN GitHub repository. Standards work best when shaped by the teams who will implement them.
The working group seeks feedback to ensure these specifications solve real problems, not theoretical ones. If you're running MCP servers, trying to standardize authorization across multiple APIs, or struggling with the confused deputy problem in AI workflows, this is your chance to influence the design before it's finalized.
