Meeting Notes 2026-04-09

Attendees

• Alex Olivier
• Atul Tulshibagwale (CrowdStrike)
• Roland Baum
• Michiel Trimpe
• Vladi Berger
• Alex Babeanu
• David Brossard
• George Fletcher
• Mark Berg
• John Jiang
• Baba Syed
• Julio Auto De Medeiros
• Alex Babeanu
• Edmund Jay

Agenda

• Actions from last week
• MCP Profile
  • Final commments on PR
  • Proposal on mailing list
• What tooling do implementors want?
  • Atul's experience from caep.dev
• Obligations 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

• AlexO: Review the final PR changes.
• AlexB: Alternate use case approach:
  • Direct mapping
  • COAZ mapping
  • Gateway implementation
• AlexB: Should the implementation be part of the spec?
• Atul: Does adding a couple of further sections to the profile solve this? The gateway is not required, but supported
• AlexB: We should add more ways to use it if that is an option
• Atul: We are just saying it is possible to use a gateway
• AlexO: Add a 1:1 mapping between MCP RPCs to AuthZEN requests. Need to be aware of changes
• Next Steps:
  • Get the PR mereged for CEL
  • AlexO work on a static mapping preamble

Tooling

• Atul: Caep.dev website has been very useful for SSF community to test against. Is there any interest for having the eqivalant for AuthZEN. Idea being if you are developing a PEP or PDP to test against.
• Roland: Would be interested in having something like that. It is a natural choice to connect AuthZEN to SSF for risk values.
• Atul: Seperate to caep.dev just a testing harness for PEP and PDP implementors
• David: We have http://authzen.guide/ which is a static reference. Keen to have a mock PDP. Should it be OIDF driven?
• Atul: OIDF support it due to its non-commerical nature. SGNL engineers did all the work.
• AlexO: What woudl it need?
• Roland: Need a way to
• Michiel: Haven't felt the need for online simulator. Aligning the resources etc is 95% of the work - the PEP/PDP is not much work. Would like language bindings/SDKs. Some way to have a sandbox for a PDP setup with policy.
• Atul: That is interesting - a PDP in the sky - with a way to define policies some way
• Edmund: would we be interested in putting this in the certification harness?
• Roland: PEP instances for certain frameworks, easy environment spinning up etc. Real world implementations need to consider the update path.
• Next steps
  • Agree on the direction - will develop idea further

Obligations

• AlexB: Limited progress
• Michiel: Getting some use cases. What to provide filters, but in the context of a resource. The classic partial evaluation use case.
• AlexB: You can already do this with context. We need to agree on the definition of obligation.
• Michiel: Things as a PEP you must adhere to or reject the request.
• AlexB: The suggestion was to make this a proper profile for obligations.
• Michiel: Need to align on the negogiation part before we can continue.
• AlexB: There is a starting point as PR on the repo.
• DavidB: XACML profile https://hackmd.io/csAsA5RSTuixU1u2uwgsAg. Should the feilds be prefixed/namespaced
• Atul: We haven't defined anything on this yet - once we do any profiles should map to that rather than define its own feilds
• DavidB: The XACML decision can be permit, deny, not applicable, inderminate. It would be nice if AuthZEN response context element could return the original XACML decision also. So a key like context.xacml.decision would be used
• Should we police ourselves?
• Michiel: We don't have IANA keys so going to have to be convention.

AOB

Actions