[Openid-specs-authzen] Updated COAZ proposal

[Alex Babeanu]

Thanks Julio, this is exactly also what Martin and I were also saying.

We should first agree on those MCP Message <--> AuthZEN mappings, the right
way to express build an AuthZEN request from an MCP Message.

In my view, how these mappings are advertised to outside, upstream systems
(for example, via MCP Tools definitions as proposed here) is secondary.

At this point, I propose we first focus on the actual mappings, maybe
revisiting also Martin's draft, to complement Atul's mappings. That would
mean amending the proposal by expanding the mappings section, etc.

And to be honest, I'll mention this again: exposing the mappings externally
is really an MCP Profile. I still think this should be broken out into its
own, separate profile.... for MCP, not AuthZEN. My $0.02.

Cheers,

./\.

On Fri, Mar 20, 2026 at 5:46 AM Julio Auto De Medeiros (BLOOMBERG/ 731 LEX)
via Openid-specs-authzen <openid-specs-authzen at lists.openid.net> wrote:

> 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:00
> To: 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 listOpenid-specs-authzen at lists.openid.nethttps://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>


-- 
Alex Babeanu

Lead Product Manager
AI Control Suite
[image: mobilePhone] +1 604 728 8130
[image: emailAddress] <https://mail.google.com/mail/u/0/goog_101932960>
alex.babeanu at indykite.com
[image: website] www.indykite.com
[image: linkedin] <https://www.linkedin.com/in/ababeanu/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20260320/5d507fe0/attachment-0001.htm>