first draft of AuthZen profile for MCP

[tulshi]

Preview this proposal here

[RobinVanhove]

The HTML and XML files are derived from the makrdown right? So I see no reason to check it into the git repo.

[RobinVanhove]

Apparently I can't reploy on the mailinglist so I'll post my thoughts here.

If I understand it correctly to proposal is that the MCP server provides the COAZ mapping of tool parameters to the AuthZEN evaluation request.
Essentially requiring that the MCP server implementing the tool is aware that it will have to authorized by this AuthZEN MCP profile and developed as such.

In practice no MCP server has implemented this, and tool developers might be slow to adopt.

If I want to secure some MCP server that does not implement this mapping, it might be interesting to have a different way of providing the mapping to the gateway. The mapping should remain consistent as long as the tool API does not change.

Providing the mapping separately would make it possible to secure any MCP server without AuthZEN specific changes.

BTW: I like using SARC as an abbreviation for Subject, Action, Resource, Context.

[tulshi]

If I understand it correctly to proposal is that the MCP server provides the COAZ mapping of tool parameters to the AuthZEN evaluation request.

That is correct.

Essentially requiring that the MCP server implementing the tool is aware that it will have to authorized by this AuthZEN MCP profile and developed as such.

In practice no MCP server has implemented this, and tool developers might be slow to adopt.

It is possible for an MCP Gateway to intercept the response from the list tools call, and add this mapping when it returns the response to the client. How the MCP Gateway defines that mapping in the first place could be a proprietary implementation detail.

If I want to secure some MCP server that does not implement this mapping, it might be interesting to have a different way of providing the mapping to the gateway. The mapping should remain consistent as long as the tool API does not change.

Providing the mapping separately would make it possible to secure any MCP server without AuthZEN specific changes.

There is merit to specifying this mapping separately too, we can add that to the draft.

BTW: I like using SARC as an abbreviation for Subject, Action, Resource, Context.

[RobinVanhove]

It is possible for an MCP Gateway to intercept the response from the list tools call, and add this mapping when it returns the response to the client. How the MCP Gateway defines that mapping in the first place could be a proprietary implementation detail.

In this case one would diverge from this proposed spec because the MCP server does not provide the mapping right?

Other that that, how does this proposal compare to @embesozzi at #429 according to you? Do they try to fix the same problem?

[tulshi]

It is possible for an MCP Gateway to intercept the response from the list tools call, and add this mapping when it returns the response to the client. How the MCP Gateway defines that mapping in the first place could be a proprietary implementation detail.

In this case one would diverge from this proposed spec because the MCP server does not provide the mapping right?

Not really, the spec can be the same. The response from the MCP Server need not include the mapping. It can be added by the Gateway in the response to the client.

Other that that, how does this proposal compare to @embesozzi at #429 according to you? Do they try to fix the same problem?

Martin can probably answer this better, but my understanding is that #429 proposes a general architecture, and this provides a specific mapping for MCP tools to become AuthZen compatible.

[embesozzi]

My idea was to define an implementation-agnostic mapping between the MCP request and the AuthZEN request model to simplify adoption.
Once this step is completed, you can choose how to implement it - whether the MCP Server advertises the mapping based on COAZ with the implementation handled in the MCP gateway, or whether it is implemented directly in the MCP Server or the gateway using an SDK, while adhering to the recommended mapping.

[baboulebou]

I agree with @embesozzi's last comment here: the MCP Message <-> AuthZEN mapping is key, the same mapping can then also be used in the coaz response.

As a 1st step, I'd suggest discussing specifically that mapping and agreeing on what that could look like. The coaz MCP extension then becomes trivial imho, it just reuses the same mapping.

[tulshi]

I agree with @embesozzi's last comment here: the MCP Message <-> AuthZEN mapping is key, the same mapping can then also be used in the coaz response.

As a 1st step, I'd suggest discussing specifically that mapping and agreeing on what that could look like. The coaz MCP extension then becomes trivial imho, it just reuses the same mapping.

This mapping is exactly what COAZ is all about.

[julioauto]

I mentioned this on a couple of meetings but forgot to add a comment to formalize it - sorry.

I think we should make x-coaz-mapping an array of JSON objects instead of a single JSON object. The semantics would be that a tool may require that more than one privilege are to be checked. We should probably work on an example to illustrate this need realistically.

The current example has a tool like get_customer <customer> <case_number>, with a mapping to evaluate if the subject/user/actor has permissions for action get_customer on resource customer under context case_number.

A multi-mapping example could be something like copy_object <location_A> <location_B> with mappings:

• action read, resource location_A
• action write, resource location_B

Then the PDP must be requested one /access/v1/evaluations or multiple /access/v1/evaluation, according to its capabilities.

Of course the resources don't have to be of the same type, neither does the subject need to be the same. I'm sure we can produce more creative and powerful examples if we want to 🙂

[baboulebou]

This could work, but:

• in your JSON schema, id is not explicitly mandatory. This is a good actually, as it would allow for Searches.
• And then the proposal is missing support for the Search APis. For example, if my MCP server exposes a tool called get_customers, then you'd omit the resource.id and the PEP would make is a resource Search. Same with the other searches...

[baboulebou]

Let me elaborate...
This proposal, essentially mixes 2 things, which I think should be broken-up in 2 proposals/PRs:

1. the actual MCP profile, which explains how to bind the MCP Messages to AuthZEN Request. As mentioned above, the current proposal lacks the Searches so far. But anyway, this is the part that we should discuss in priority.

2. your coaz MCP profile, which should really be an extension to MCP, imho. I know they didn't want it there, but the first question here is whether AuthZEN is the right place for it at all. And if yes, then it should definitively be a separate "thing" (profile or at the very least PR).

My problem with this MCP profile, is that you're in-effect externalizing the fine-grained access control to the client (your Gateway, say). By extension, I don't see why that Client couldn't also perform the Searches then ? After all, a set of evaluations could result in the same data being returned as one search. I am a fan of separating concerns, a gateway should not I think behave like an MCP server, it should be a PEP, not a resource server.

And by extension, the Gateway could perform coarse access control only really. And in that sense, a Resource Search where action=mcp_tool and resource.type=mcp_server_url, or similar, makes sense there,,

Anyway I think this should be discussed much further.

[tulshi]

Thanks @baboulebou , my comments below:

Let me elaborate... This proposal, essentially mixes 2 things, which I think should be broken-up in 2 proposals/PRs:

1. the actual MCP profile, which explains how to bind the MCP Messages to AuthZEN Request. As mentioned above, the current proposal lacks the Searches so far. But anyway, this is the part that we should discuss in priority.

I'm not sure I understand. This is exactly what the COAZ mapping does.

2. your coaz MCP profile, which should really be an extension to MCP, imho. I know they didn't want it there, but the first question here is whether AuthZEN is the right place for it at all. And if yes, then it should definitively be a separate "thing" (profile or at the very least PR).

If we address your point 1. above, we will have more clarity on this one.

My problem with this MCP profile, is that you're in-effect externalizing the fine-grained access control to the client (your Gateway, say). By extension, I don't see why that Client couldn't also perform the Searches then ? After all, a set of evaluations could result in the same data being returned as one search. I am a fan of separating concerns, a gateway should not I think behave like an MCP server, it should be a PEP, not a resource server.

As I've stated previously, the client could do any prior AuthZ checks it wants, but the server or a gateway, if it exists, won't trust those decisions, and will want to do the checks themselves. The COAZ mapping being in the List Tools response helps the client understand how the parameters will be interpreted by the server from an authorization perspective.

And by extension, the Gateway could perform coarse access control only really. And in that sense, a Resource Search where action=mcp_tool and resource.type=mcp_server_url, or similar, makes sense there,,

I'm not sure I understand the search use case, but we can discuss it. The COAZ mapping works to get a simple authorization answer to MCP tool calls.

Anyway I think this should be discussed much further.

Happy to discuss in the call this week.

[tulshi]

My problem with this MCP profile, is that you're in-effect externalizing the fine-grained access control to the client (your Gateway, say). By extension, I don't see why that Client couldn't also perform the Searches then ? After all, a set of evaluations could result in the same data being returned as one search. I am a fan of separating concerns, a gateway should not I think behave like an MCP server, it should be a PEP, not a resource server.

I think I realize the core misunderstanding about the COAZ proposal. It is not meant for a client to make access decisions. It is for an MCP server to make access decisions, but in a way that is exposed to the client, and in such a way that a Gateway could enforce the access decisions on behalf of the server. Does that make sense?

The abstract actually says this almost exactly. Is there somewhere else in the spec you think I should add this information to make it unambiguous that I'm not proposing the mapping to be enforced by the client?

[baboulebou]

Thanks for the reply and clarification. Let me then try to also clarify. In any case, I think this should be debated with the wider group:

This quote from your proposal is my main concern:

"The response to the tools/list call of MCP has the inputSchema in it. The inputSchema declares whether the tool is COAZ or not."

My concern here is that it is, really, a profile on MCP, not on AuthZEN. And I know the MCP group didn't want that profile, I did follow that discussion, but I question whether we are the right group for proposing this.

Instead, I though that we could focus first on the simpler use-case. Forget Gateways or Clients; how can a MCP Tool implementer include a PEP in the tool code itself (where fine-graine AuthZ actually makes sense), and map input MCP message to AuthZEN payload? Again, for this part, the MCP tool doesn't have to advertise anything at all to the client or outside world.

And actually, I think this may be sufficient for our AuthZEN purposes...

[tulshi]

Thanks for the reply and clarification. Let me then try to also clarify. In any case, I think this should be debated with the wider group:

This quote from your proposal is my main concern:

"The response to the tools/list call of MCP has the inputSchema in it. The inputSchema declares whether the tool is COAZ or not."

My concern here is that it is, really, a profile on MCP, not on AuthZEN. And I know the MCP group didn't want that profile, I did follow that discussion, but I question whether we are the right group for proposing this.

I guess my test for whether this is valuable to AuthZen or not is to check whether implementers of AuthZen - either PDPs or PEPs would benefit from something like this. I feel we will benefit, and therefore it can belong here.

Instead, I though that we could focus first on the simpler use-case. Forget Gateways or Clients; how can a MCP Tool implementer include a PEP in the tool code itself (where fine-graine AuthZ actually makes sense), and map input MCP message to AuthZEN payload? Again, for this part, the MCP tool doesn't have to advertise anything at all to the client or outside world.

I'm not sure what you are proposing should be "instead of" the COAZ proposal. It could be in addition to the COAZ proposal.

And actually, I think this may be sufficient for our AuthZEN purposes...

I disagree, because I think we need a standardized way of communicating to an AuthZen PDP from an MCP Server or Gateway in order to offload access decisions to a PDP, and COAZ defines that.

[vatsalgupta]

This is helpful and clarifies that identity is expected to be present via context and/or subject, with at least one field derived from the token.

One question I had while reading this:
For autonomous agent scenarios, the profile requires inclusion of both:

• the agent identity, and
• the user identity on whose behalf the agent is acting

However, it is not fully clear whether the profile intends to standardize the relationship between these identities, or only ensure that both are available as inputs to the authorization decision.
For example, different implementations could represent this in different ways:

• agent as subject, user in context
• user as subject, agent in context
• both encoded in context with custom structure

From an authorization and audit perspective, the distinction between:

• acting on behalf of a user
• acting as a user
• autonomous agent actions

can be significant.

Is the intent of the profile to:

• leave this relationship fully implementation-defined, or
• eventually define a more consistent model for representing delegation (e.g., agent acting on behalf of user)?

Curious how others are thinking about this, especially for interoperability and audit use cases.