[Openid-specs-authzen] [External] Re: Updated COAZ proposal

Wed Mar 25 16:52:02 UTC 2026

Hi Martin,
FYI,  the COAZ mapping doesn't change the MCP schema in a way that requires
any validation by the MCP community. I think you are referring to COAZ in
his email, but I'm not sure.

On Wed, Mar 25, 2026, 6:58 AM Martin Besozzi via Openid-specs-authzen <
openid-specs-authzen at lists.openid.net> wrote:

> 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
>>>> [github.com]
>>>> <https://urldefense.com/v3/__https://github.com/openid/authzen/pull/435__;!!BmdzS3_lV9HdKG8!zdGcCcwOskxtdzGTBiSUN3HlHfI0nf45qJnS9P8ISWpfXlNfDhdCixE4h7JvTvxd75WDrg36Xm64L4ZxiCCsgeGkVbX_6cPHxlXF-Cc6JjEs$>
>>>>
>>>> Thanks,
>>>> Atul
>>>>
>>>> --
>>>> Openid-specs-authzen mailing listOpenid-specs-authzen at lists.openid.nethttps://lists.openid.net/mailman/listinfo/openid-specs-authzen [lists.openid.net] <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-authzen__;!!BmdzS3_lV9HdKG8!zdGcCcwOskxtdzGTBiSUN3HlHfI0nf45qJnS9P8ISWpfXlNfDhdCixE4h7JvTvxd75WDrg36Xm64L4ZxiCCsgeGkVbX_6cPHxlXF-CQ_Ip22$>
>>>>
>>>>
>>>> --
>>>> Openid-specs-authzen mailing list
>>>> Openid-specs-authzen at lists.openid.net
>>>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>>> [lists.openid.net]
>>>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-authzen__;!!BmdzS3_lV9HdKG8!zdGcCcwOskxtdzGTBiSUN3HlHfI0nf45qJnS9P8ISWpfXlNfDhdCixE4h7JvTvxd75WDrg36Xm64L4ZxiCCsgeGkVbX_6cPHxlXF-CQ_Ip22$>
>>>>
>>>
>>>
>>> --
>>> Alex Babeanu
>>>
>>> Lead Product Manager
>>> AI Control Suite
>>> [image: mobilePhone] +1 604 728 8130
>>> [image: emailAddress] [mail.google.com]
>>> <https://urldefense.com/v3/__https://mail.google.com/mail/u/0/goog_101932960__;!!BmdzS3_lV9HdKG8!zdGcCcwOskxtdzGTBiSUN3HlHfI0nf45qJnS9P8ISWpfXlNfDhdCixE4h7JvTvxd75WDrg36Xm64L4ZxiCCsgeGkVbX_6cPHxlXF-KugsAYe$>
>>> alex.babeanu at indykite.com
>>> [image: website] www.indykite.com [indykite.com]
>>> <https://urldefense.com/v3/__https://www.indykite.com/__;!!BmdzS3_lV9HdKG8!zdGcCcwOskxtdzGTBiSUN3HlHfI0nf45qJnS9P8ISWpfXlNfDhdCixE4h7JvTvxd75WDrg36Xm64L4ZxiCCsgeGkVbX_6cPHxlXF-A55p8fv$>
>>> [image: linkedin] [linkedin.com]
>>> <https://urldefense.com/v3/__https://www.linkedin.com/in/ababeanu/__;!!BmdzS3_lV9HdKG8!zdGcCcwOskxtdzGTBiSUN3HlHfI0nf45qJnS9P8ISWpfXlNfDhdCixE4h7JvTvxd75WDrg36Xm64L4ZxiCCsgeGkVbX_6cPHxlXF-I2xyD8d$>
>>> --
>>> Openid-specs-authzen mailing list
>>> Openid-specs-authzen at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>> [lists.openid.net]
>>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-authzen__;!!BmdzS3_lV9HdKG8!zdGcCcwOskxtdzGTBiSUN3HlHfI0nf45qJnS9P8ISWpfXlNfDhdCixE4h7JvTvxd75WDrg36Xm64L4ZxiCCsgeGkVbX_6cPHxlXF-CQ_Ip22$>
>>>
>> --
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>> [lists.openid.net]
>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-authzen__;!!BmdzS3_lV9HdKG8!zdGcCcwOskxtdzGTBiSUN3HlHfI0nf45qJnS9P8ISWpfXlNfDhdCixE4h7JvTvxd75WDrg36Xm64L4ZxiCCsgeGkVbX_6cPHxlXF-CQ_Ip22$>
>>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
>
> https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-authzen__;!!BmdzS3_lV9HdKG8!zdGcCcwOskxtdzGTBiSUN3HlHfI0nf45qJnS9P8ISWpfXlNfDhdCixE4h7JvTvxd75WDrg36Xm64L4ZxiCCsgeGkVbX_6cPHxlXF-CQ_Ip22$
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20260325/8d7ee343/attachment-0001.htm>