Explain why the COAZ mapping is needed

[tulshi]

From @ogazitt in the AuthZen call on 4/16.
Most MCP developers may not be familiar with the AuthZen model, so it makes sense for the spec to explain why it is needed.

[ogazitt]

I think there's a layering here that could be helpful to tease out.

--
[Independently of MCP] AuthZEN is predicated on an underlying architectural principle - the externalization of authorization. We have standardized a wire format for asking and answering the question "can this subject perform this action on this resource".

A logical next step in the adoption of the externalized authorization architecture is to define a metadata format for the fine-grained authorization call(s) that must be performed before the target logic is executed.

Traditionally, metadata is helpful for many applications - from WSDL to OpenAPI, metadata helps drive proxy creation, payload validation, authentication requirements, and other aspects.

We want to define ways to embed authorization requirements in existing metadata formats. Two obvious targets:

• OpenAPI definitions: it would be helpful to define how an intermediary could perform authorization as a gate before handing off execution to the REST endpoint. This could be done by a gateway or by an interceptor for languages that support this type of construct.
• MCP tool and resource definitions: it would be helpful for a similar intermediary (e.g. MCP gateway, or an MCP server implementation framework) to be able to apply an AuthZEN evaluation(s) call before handing off execution to the tool or retrieving the resource.

It would be nice if the way this metadata is structured was symmetric between these use-cases, and utilized CEL as the expression language.

CoAZ would be the "MCP binding" of this idea. It would be packaged as a profile of the MCP metadata format, and adhere to the MCP design aesthetics.

Core to the CoAZ metadata extension would be two things:

1. A default binding from the MCP jsonrpc "information model" to the AuthZEN information model - e.g. subject.type: "identity", subject.id = "@jwt.sub", etc. This is @alexolivier 's proposal.
2. An override mechanism that allows specific parts of the AuthZEN information model to be populated by the MCP information model. This is @tulshi 's current proposal.

Once we are able to firm this up, the same exact playbook could be applied to REST API's via defining a standard metadata extension for OpenAPI definitions.

Additionally, many languages contain annotation capabilities that are practically used by frameworks to perform some functions. For example, using JSDoc along with swagger-jsdoc, one can auto-generate the OpenAPI definition for a web API endpoint. These existing extension points would be great targets for the AuthZEN community to go after, so that developers can declare how authorization is expected to be externalized for their function.