Meeting Notes 2026-04-16

Attendees

• Alex Olivier
• Alex Babeanu
• Atul Tulshibagwale (CrowdStrike)
• Omri
• John Gren
• Mike Kiser
• Vladi Berger
• Roland Baum
• Michiel Trimpe
• Gilbert
• Edmund Jay
• Julio de Medeiros
• Vatsal Gupta
• George Fletcher

Agenda

• MCP Profile
  • Feedback from MCP community (Atul) *
  • Proposal of mapping
  • Open questions
    • Do all messages require authZ? eg initialize/ping
    • What is the model for elicitation/sampling?
    • Managing the evolution inline with the MCP spec
• Obligations proposal
• Should we revive the AuthZEN in RAR proposal?
• Upcoming talks - who else will be there?
  • OIDF pre-IIW (AlexO, Atul)
  • EIC (David, AlexO) - AuthZEN + OIDF Workshop
  • Identiverse session + workshop
  • Possible Forrester engagement
• Certification progress

Notes

### MCP Profile

• Omri: Trying to understand the actors in the play. If an MCP server is fine-grained authz. If the MCP server is its own PEP, then not a lot to do. Candidate is the gateway as the main audience.
• Atul: Believe even if you have MCP server doing the check, it will still help to have this defined so the server doesn't need to know about it. If enterprise deploy 100s of MCP server then it can be a global mapping.
• Omri: Handled by a service?
• Atul: Could be a filter/middleware
• Omri: Mapping makes resonable sense to map from MCP RPC to SRAC model. Better to have a cancnocal mapping. Analogue to API profile. Value in the MCP gateway to do this for coarse-grained authz.
• Atul: We cannot escape fine-grained, even if something happens upstream.
• Omri: A server can't rely on a gateway to do fine-grained. The gateway is this a first line of defense. Latency isn't so much of an issue in MCP model so doing multiple checks is ok.
• Atul: Maybe thinking this differently. Having a single check that can do the fine-grained check they why do the multiple ones.
• Omri: When I think of API authz - the target has been the PEP. Its the app code which maps data to the authzen model. Hard to see how the coaz mapping helps the code in the MCP layer.
• George: Agree with Atul that could end up doing AuthZ twice. The gateway layer check is determine if the requesting entity be allowed to invoke entity/tool. Want to answer that early in the chain as possible. You don't want the load on the resource server. Harden the edge. Drop the request as far out of the infra as possible.
• Omri: Example. Gateway asks can George invoke this tool. Tool asks can this tool be invoked by these parameters
• Mike: Not clear if MCP world if there is enough data for making the decision.
• Michiel: Seem to have consenus on 'mechanical' mapping. Focus on that?
• Atul: You get all the context in every request - why not use it? If you want to further restrict things like this transaction requires a fraud check etc - that is a realisation that the application layer might have which may not be apparent from the context.
• AlexB: Skeptical if there will all the context to be made everytime to have the complete picture. If we expose the mapping they can be used for whatever purpose. Would use it to express the intent of the tool. It would be coarse level at this point. Doesn't matter aslong as we agree on the mapping.
• Atul: With the coaz you have the opporunity to do the mapping as much as you want.
• AlexB: We should be oppinionated about that part.
• Omri: Replaying - it would be interesting to have the RPC to tell the world the set of checks you need to run before passing the request to be invoked. We should write down the actors involved. MCP viewpoint is that the tool knows everything why do I need this?
• Omri: Should the mapping just be the full AuthZEN request (with CEL)?
• AlexB: Current version has arrays which doesn't map to the AuthZEN evaluations syntax - why don't we just use that.
• Vatsal: Current proposal, this is configured on the MCP side for every tool on the mapping. The PEP will make the call which call to make?

AOB

Actions