[Openid-specs-authzen] Updated COAZ proposal

Wed Mar 25 13:58:09 UTC 2026

Hi all,
It may be useful to structure the work across several tracks.

The first track could simply focus on the mapping between the MCP message
and the AuthZEN request. My recommendation is to avoid changing the MCP
schema, as this would require validation by the MCP community, support
across MCP SDKs (some SDKs still lack support for MCP app extension _meta
tags), and additional overhead. Instead, we should keep the approach simple
(following the KISS principle).

This can serve as an MCP profile for any PEP in gateways, as well as for
MCP servers handling the mapping, as it would help drive AuthZEN adoption
without introducing additional requirements.

Regards,
Martin

On Sat, Mar 21, 2026 at 8:53 PM Atul Tulshibagwale via Openid-specs-authzen
<openid-specs-authzen at lists.openid.net> wrote:

> Hi Julio,
> Thanks for your thoughtful critique. To distill the issues you see with
> the COAZ proposal, they are:
>
>    1. No canonical mappings exist for MCP action names, resource types,
>    etc. to AuthZen
>    2. It doesn't address whether this MCP tool, resource, or prompt can
>    be called right now.
>
> I'll clarify these issues based on the existing proposal:
>
>    1. There is a default action name mapping in the COAZ proposal. If the
>    action is not specified, the tool name is used. It does not apply to
>    resources and prompts, but in my experience, most MCP servers only care
>    about tools. So in my mind, it should be OK to focus on tools for now, and
>    extend to resources and prompts as needed. We could potentially extend this
>    default mechanism to the resource parameter of the AuthZen call. If the
>    resource parameter is not specified in the COAZ mapping, the resource name
>    is also the tool name (i.e., the same as the default action value).
>    2. A PDP can determine whether to allow a tool call by focusing only
>    on the tool name as the parameter in the AuthZen request that it bases its
>    decision on. It doesn't always require fine-grained authorization, but it
>    can if necessary.
>
> Thanks,
> Atul
>
> PS:  I'm a bit surprised by Alex's repeated question about whether this
> belongs in AuthZen, especially since he noted in Thursday's call that he
> sees value in using COAZ for his work. I think this is super relevant to
> the AuthZen community, so I'm not sure why this is a question.
>
>
> On Fri, Mar 20, 2026 at 9:39 AM Alex Babeanu via Openid-specs-authzen <
> openid-specs-authzen at lists.openid.net> wrote:
>
>> 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/>
>> --
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net
>> https://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20260325/d8a0a2bb/attachment-0001.htm>