[Openid-specs-authzen] Updated COAZ proposal

[Julio Auto De Medeiros (BLOOMBERG/ 731 LEX)]

After the call yesterday I thought a bit more about MCP profiles for AuthZEN. My understanding is that some folks would like canonical mappings of MCP concepts into AuthZEN elements: what are the action names to be used, what are the resource types, etc. That's precisely what Martin's proposal does, and that's what I'd normally think of as a "profile" as well.

The COAZ spec doesn't really do that, and as far as I can tell that's purposefully so.

First we must acknowledge that the COAZ proposal really only cares about tool calling. And I think there's an implicit premise underlying the proposal that says something like: permission to call a tool can (most often?) be distilled into permissions for downstream resources.

If I own an MCP server that has a `get_file` tool, for example, I may have this server invoke /evaluation on an AuthZEN PDP to check:
1. SUBJECT can call_MCP_tool on resource tool:get_file with context input[0]="bucket/secret.txt" <--- i.e., a sort of canonical, standardized construct

Or:
2. SUBJECT can read_object on resource object:bucket/secret.txt <--- i.e., particular to the tool implementation and the resources it depends on

I find the second option a more natural candidate for adoption, because MCP tools mostly front existing systems with pre-defined permission models. So the PDP can be made to speak the lingo and use the resource permissions that already exist. What the COAZ proposal does is establish a mechanism via which these implementation-specific mappings can be surfaced to upstream callers in a standardized manner, exposing a contract between the inputs and authorization checks (and optionally allowing for upstream callers to function as PEPs too, in the example of an MCP Gateway). To be pedantic, the COAZ spec DOES specify some mapping rules too, like "At least one field of the subject MUST be derived from the $.token variable", but I find that for the most part it allows great flexibility for the mapping definition.

Now, this really only applies to tool calling. For everything else in MCP I think we still should define canonical mappings:
- Can SUBJECT list the tools on this server?
- Can SUBJECT fetch the prompts offered by this server?
- ...

I don't expect the questions above to naturally match other actions and resources, so they'd benefit from strict standardization.

As a final note: I suppose there could be tool-calling scenarios where both evaluations previously mentioned are relevant. From my get_file example, the first evaluation ("SUBJECT can call_MCP_tool [...]") might be used to, say, check if the user has been enabled for MCP access, while the second evaluation is really validating permissions for the underlying resources the tool acts on. If we agree we need both, I'd be OK with that; seems like distinct semantics to me.

In a nutshell, I'm not sure COAZ is a typical "profile" per se, but I think it serves an important purpose and fits a probable pattern: MCP servers using AuthZEN to check downstream resource permissions rather than a literal "can SUBJECT call this tool?".

    Julio Auto

From: openid-specs-authzen at lists.openid.net At: 03/13/26 22:33:13 UTC-4:00To:  Openid-specs-authzen at lists.openid.net
Cc:  atul at sgnl.ai
Subject: [Openid-specs-authzen] Updated COAZ proposal

Hi all,
I've updated the COAZ PR to incorporate Julio's comment about multi-valued parameters. Please review here: https://github.com/openid/authzen/pull/435

Thanks,
Atul

         -- 
Openid-specs-authzen mailing list
Openid-specs-authzen at lists.openid.net
https://lists.openid.net/mailman/listinfo/openid-specs-authzen
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20260320/d4ed05ee/attachment.htm>