By Atul Tulshibagwale and Alex Olivier, co-chairs of the OpenID Foundation’s AuthZEN Working Group
The views expressed in this post are those of the authors, in their capacity as co-chairs of the AuthZEN Working Group, and do not necessarily represent the position of the OpenID Foundation as a whole.
AuthZEN is a great way to externalize authorization. But your API, protocol, or system may have a different way of expressing the parameters that are required to make such externalized authorization decisions. COAZ (pronounced “cozy”) is a framework to map operations in any source system — such as an API or protocol — to AuthZEN evaluation calls, which result in the caller knowing whether or not to let the operation proceed.
With this in mind, the OpenID Foundation’s AuthZEN Working Group is announcing the publication of two new draft specifications: the COAZ Framework and the COAZ-MCP Binding.
Since security is only as strong as its weakest link, it is important for enterprises to enforce organizational policies consistently, continuously and contextually across all their assets. However doing so in a proprietary manner for each system can be expensive, fragmented, and can end up applying policy inconsistently.
The AuthZEN Authorization API provides a standard way to request fine-grained authorization decisions using the Subject-Action-Resource-Context (SARC) model. But to do this across an organization’s technology landscape, developers still need a standardized way to translate their specific application inputs into the AuthZEN format.
That is where COAZ comes in.
The COAZ Framework: Universal Mapping for Any Protocol
COAZ (Compatible with OpenID AuthZEN) is a generalized framework for mapping the information model of any arbitrary protocol or interface into an AuthZEN Authorization request.
Whether you are securing an HTTP request, a JSON-RPC message, or an OpenAPI-described route, COAZ establishes a single, protocol-neutral pattern. It takes the inputs of an incoming operation (such as request fields, headers, and authorization tokens) and projects them into the AuthZEN SARC structure through a declarative mapping.
Instead of writing custom middleware for every new API or protocol, PEPs (Policy Enforcement Points) can rely on COAZ mappings. These mappings use literal constants and expressions — written by default in the Common Expression Language (CEL) — to dynamically construct the AuthZEN authorization request to a PDP (Policy Decision Point). The COAZ Framework is abstract, but can be instantiated for a specific protocol or API, as we have done for MCP. See below.
Example MCP mapping:
Mapping specification: |
{ "evaluation": { "subject": {"type": "identity", "id": "$token.sub"}, "action": {"name": "$tool.name"}, "resource": {"type": "customer", "id": "$params.customerId"}, "context": {"agent": "$token.?client_id", "case": "$params.caseId"} } } |
Results in actual AuthZen call: |
{ "subject": {"type": "identity", "id": "alice@example.com"}, "action": {"name": "get_customer"}, "resource": {"type": "customer", "id": "cust-12345"}, "context": {"agent": "http://agentprovider.com/agent-app-id", "case": "case-67890"} } |
COAZ-MCP: Securing the AI Agent Era
We are simultaneously releasing COAZ-MCP, the draft COAZ binding for the Model Context Protocol (MCP).
As AI agents integrate deeply into enterprise workflows via MCP, they act on behalf of users with various delegated access modes. If one is not careful about how to authorize individual MCP resource or tool invocations, it is easy to end up with a “confused deputy problem,” wherein the intended authorization at a higher level results in unauthorized access at the lower level.
In addition, authorization decisions involving agents include not just the user principal, but also the agent identity, and the relationship between them. COAZ-MCP also addresses this concern.
COAZ-MCP applies the COAZ framework directly to the MCP information model, ensuring that every JSON-RPC message from an AI client is authorized before execution:
- Default Mappings: The binding defines a fixed default mapping for each MCP method, ensuring all basic messages can be authorized without per-operation configuration.
- Declared Mappings: Individual tools can override defaults by declaring a custom COAZ mapping in the tool's input schema (using CEL). This translates dynamic tool arguments directly into AuthZEN parameters.
- Subject Identity: The binding provides a standard way to capture the distinct identity of the human user the agent is acting on behalf of.
By decoupling the security logic from the underlying business code, developers can secure MCP tools using the exact same externalized AuthZEN policy engine they use for their standard web APIs.
COAZ-MCP also enables intermediaries such as MCP Gateways to enforce the binding, thus separating the business logic (which expresses the binding) from the policy enforcement, which can be controlled by a centralized IT team managing the gateway.
Get Involved
The publication of the COAZ Framework and the COAZ-MCP Binding drafts marks a significant step forward in interoperable, externalized authorization for both traditional APIs and the emerging agentic web. These are currently just drafts; they will go through a maturity process, wherein a future version will be proposed as an “Implementer’s Draft” ratified by the OpenID Foundation as a whole, and eventually, the OpenID Foundation will ratify a “Final Version”.
So, right now is a great time for identity professionals, security architects, and developers to review and contribute to the draft specifications, which are now available on the OpenID AuthZEN GitHub home page. Do COAZ and COAZ-MCP address your immediate needs? Is there something you would like COAZ to address that the current draft doesn’t? Notice anything inconsistent / contradictory in the drafts? You can create issues for any feedback you have.
Join the AuthZEN Working Group, participate in our GitHub discussions, and help us shape the future of standardized authorization!
About the authors:
Atul Tulshibagwale is co-chair of the OpenID AuthZEN Working Group, as well as Senior Director of Continuous Identity Strategy at CrowdStrike, following its acquisition of SGNL, where he was CTO. Atul is a federated identity pioneer and the inventor of CAEP. Earlier, he was a Software Engineer at Google, where he conceptualized the Continuous Access Evaluation Protocol (CAEP), which forms a basis of the Shared Signals and Events working group in the OpenID Foundation. Previously, he was a co-founder and the CEO of Trustgenix (acquired by Hewlett Packard), where he defined the federation server, a concept that was later adopted by almost all identity vendors. He helped define open standards such as the Liberty Alliance and SAML 2.0. He continued with HP as the Director of Federation.
Alex Olivier is co-chair of the OpenID AuthZEN Working Group, as well as the co-founder and Chief Product Officer at Cerbos, an Authorization Management Platform and implementer of the AuthZEN standard. He specializes in authorization systems, with a recent focus on workload identity and AI security. With over a decade of experience building and scaling authorization systems at Microsoft, Qubit, Zencargo, and multiple startups, Alex has published extensively on securing Model Context Protocol (MCP) servers and AI agents. A frequent speaker at events on authorization, AI, security, and identity, including ISC2 Congress, Identiverse, EIC, KubeCon, and Google Cloud NEXT, he combines standards development with practical implementation experience, focusing on the future of authorization for traditional applications, distributed workloads, and emerging AI systems.
About the OpenID Foundation
The OpenID Foundation (OIDF) is a global open standards body committed to building trusted identity ecosystems. Our mission is to lead the global community in identity standards that are secure, interoperable, and privacy respecting. Founded in 2007, we are a community of technical experts. The Foundation's OpenID Connect standard is now used by billions of people across millions of applications. More recently, the FAPI security profile - built on OAuth 2.0 - has become the standard of choice for interoperable Open Banking and Open Data implementations, while OpenID for Verifiable Credentials specifications are underpinning a new generation of digital wallets. Today, the OpenID Foundation's standards are the connective tissue that enable people to assert their identity and access their data at scale, the scale of the internet, enabling "networks of networks" to interoperate globally. Individuals, companies, governments and non-profits are encouraged to join or participate. Find out more at openid.net.
