Meeting Notes 2026-03-19

Attendees

• Alex Babeanu
• John Jiang
• Julio Auto
• Omri Gazitt
• Atul T
• Michiel Trimpe
• Martin Besozzi
• Edmund Jay
• Roland Baum
• Atul Tulshibagwale (CrowdStrike)
• Alex Olivier

Agenda

• Actions from last week
• MCP Profile
• Obligations Proposal
• Upcoming talks - who else will be there?
  • EIC (David, AlexO)
  • Possible Forrester engagement
  • Possible Identiverse session
  • Authenticate CFP (David, AlexO)
• Certification progress (Edmund adding to harness)

Notes

Obligations Proposal

• Omri got authzen-interop site back up.
• Omri, about obligations:
  • Any proposal must be backwards compatible
  • Obligation should be optional: "old" PEPs should still be valid.
  • "Old" PEP may not be obligation-capable at all, in that case the requirement to force the "old" PEPs to deny if they don't understand obligations would break backward compatibility.
  • Obligations should be a profile, there's too much there. Also we may add additional normative obligations in the future.
• Atul: negotiation would break the current simple REST standard.
• Atul: This could be done through some kind of configuration information rather than a negotiation over the wire.
• Omri: This could be done using the metadata of the PDP
• Omri: Once the PEP and PDP understand the capabilities, you can include the PEP supported obligations in the request, and the PDP can respond accordingly.
• Michiel: We can't use the existing "evaluation(s)" API because it will break backward compatibility
• Michiel: How you do the negotiation is another aspect of this. Whether we do it through metadata or through the protocol.
• Alex B: Let's not call it negotiation. We already have the metadata for that.
• Michiel: Some older PDPs consider partial evaluations as obligations
  • Alex B: I disagree
• Omri: Since Alex B is going to revise the proposal (based on my feedback), the new proposal will not break backward compatibility
• Alex B: Filters, conditions are supported in the spec. We can put whatever we want in the context
  • Omri: We added context later, and we specifically excluded obligations from v1. We added request / response context only as a way to signal capabilities to each other.
• Atul: if we add context which is loosely defined, then we are not saying it is critical to interopabitliy. Moment we put structure in that object then it will break backward compat.
  • Omri: only if its required
  • Michiel: its required as if we are saying if a obj must be followed.
• Omri: if the PDP wants to maximise the chance the PEP does something, then it has to look at the list of the client supported obligations, then it should just issue a DENY. If there is a matching obligation, then it should return the ALLOW with the obligation. Old clients will just get the deny and keep functioning, new clients will work as expected.
• AlexB: an obligation is not required on every response, it can't be manditory
• Atul: An obligation is a mandatory thing when its provided
• Omri: A PEP that doesn't know about obligations, should still work with PDPs which do support them. The PEP and PDP need to negogiate support, if it isn't then just return a DENY
• John: If a True decision response contains anything for the PEP to do further, it's a partial evaluation. It seems to me a response type of partial evaluation should be added.
• Michiel: We need to avoid a situation where every supported obligation needs to be provided in the request (besides wildcard).
• Michiel: A partial evaluation for a resource would be the same as a regular evaluation with an obligation to filter resources.

MCP

• AlexB: Two areas to address:
  • mapping MCP to AuthZEN request
  • advertising AuthZEN support for an MCP server
  • Atul: The modifications proposed are a profile on the MCP messages. Feedback from the MCP WGs was they don't know about AuthZEN so best placed here.
• Martin: Start with just the mapping as a first step, then expose this to the PDP could be later. The API gateway profile needs to work the same way - how to map an HTTP request object to an AuthZEN request. A proposal should be the mapping from the MCP message (eg tool/call) to AuthZEN feilds.
• Atul: Does the COAZ proposal do the mapping?
• Martin: Yes, but it is doing both the mapping and the advertisement of the support which is needed if its an MCP gateway style PEP
• Atul: In a simple MCP server and it wants to map a tool call to an AuthZEN request - does the existing proposal solve that problem?
• Martin: It does explain the mapping, but its included with a lot more context.
• AlexB: The mapping is not simple, there maybe filters/conditions needed.
• Atul: Open to proposals for how to better explain the mapping up front. Full proposal covers the complexity of the MCP spec.
• AlexB: I could use the proposal as is for my product, but the concern is the seperation of concerns. Aren't we stepping on MCP toes?
• Atul: We gave them the opportunity to be the home for this, but they don't know if AuthZEN is going to be the way forward so best to keep it here. Recommend accepting the proposal as a WG document and merge in to the main branch of the repo. Then use that to base further evolution on top of.
• Omri: Should I think of this like the API Gateway profile? The mapping from the HTTP model to the AuthZEN information model
• Atul presented the COAZ deck
  • The mapping to AuthZEN is in the x-coaz-mapping configuration returned in the message.
  • Baked in rule to require the token to be used
  • Likely swap JSONPath to CEL
• Atul: Addressed Julio's comment about supporting to Evaluations API
• AlexB: We need to agree on things like JSONPath vs CEL
• Atul: Actions are tool name or specified (with defaults)
• Omri: Fields like subject would likely always be the token sub etc
  • Atul: In autonomus agents then it won't just be a user
• Atul: We don't need to have MCP community buy in right now, but would be a win for AuthZEN if it does as then the wider option.
• Martin: MVP could just be the profile, then go to the mapping etc. We need to spend time defining the mapping from each MCP RPC.
• Atul: Tools are the main thing people care about MCP
• AlexO: This proposal works for tool/call - but can we include a way to do tool/list filtering
• Merge as is then start covering the mappings as the first iteration.

AOB

Actions

• AlexB: Update the obligations proposal and share with the WG