Meeting Notes 2026-02-12

Attendees

• @alexbabeanu
• @davidbrossard
• @alexolivier
• @DaveHyland
• Atul
• VictorLu
• Michiel Trimpe
• Jonas Primbs
• Chaithanya Yambari
• Thomas Tran
• Roland Baum
• Edmund Jay

Agenda

• Check action items from last week.
• Update from Mattermost
• AI and MCP
  • Atul's proposal
  • Martin Besozzi's proposal
• SDKs
  • RSK's contribution.
• Certification testing (Alex O)
• API Gateway profile (Gert, David)
• MCP/A2A profile (Atul, Alex B)
• Obligations profile (Alex B)
• Partial evaluation (David, Julio)
• Protocol Bindings - gRPC (Gert, Julio)
• Contact external vendors -> Adopt AuthZEN, reach-out

Notes

• Victor Lu - if agents are talking to a database, without an API layer, would AuthZen help protect that
• AlexB - an agent would talk through a tool, that is where the authzen check would be (the gateway, or the mcp server)
• AlexO - could be at the network/gateway level
• Dave - extenstion of the API gateway. Kong plugin.

Protobufs

• Gert released v1.0.1 of the ProtoBuf schema and golang bindings, replacing the v1.0.0 artifacts
  • https://buf.build/authzen/access/docs/v1.0.1
  • https://github.com/authzen/access/releases/tag/v1.0.1
  • https://github.com/authzen/access.go/releases/tag/v1.0.1

Mattermost

• They are using AuthZEN against their own internal PDP (CEL)
• They are planning to add PEP hooks in their layers (2-3 months out)
• See chat conversation.

IGA Scenario

• Chaithanya (Zluri - IGA use cases)
  • looking at implementing AuthZEN. Have setup a mock PDP with actions like should_retain_access, should_provision etc needs some clarification
  • Is the context customizable?
    • AlexB - yes, looking at adding more defintions/profiles around this?
  • Decisions are done internally - not an API call as it is a PDP also.
  • What are the use cases for search?
    • Access recertification
    • Who has access to a particular license
• AlexB - find the use case doc

AI & MCP

• @zirotrust's proposal
  • MCP WG decided not to include it in the spec currently
  • This proposal would be a proprosal in AuthZEN profile instead
  • Will submit a proposal
• @alexbabeanu

Certification

• Proposal

• Open questions

  • Certification levels: Given we have different endpoints, should we have levels?

  Level	APIs Covered	Description
  Basic	Access Evaluation	Single request/response decision
  Batch	Access Evaluations	Multiple decisions in a single request (boxcarring)
  Search	Subject Search, Resource Search, Action Search	Searching of authorized entities

  • Unknown entity types in search: The spec defines search results as "zero or more entities", so empty results for unknown identifiers within known types are clearly valid. However, the spec does not specify behaviour when the entity type itself is unrecognised by the PDP (e.g. searching for type "spaceship"). Should PDPs return an empty results array or HTTP 400?
  • Fixture size: Is the current fixture (2 subjects, 2 resources, 3 actions, 8 known decisions) sufficient? Or should it be expanded to cover more edge cases eg pagination? The tradeoff is implementer burden vs. harness coverage.
  • Pagination testing depth: Should the harness require PDPs that advertise pagination support to demonstrate multi-page results? This would require a larger fixture to generate enough results for pagination.

• Thomas - we should have a core/base profile which tests only required field

Obligations Profile

• AlexB - drafting

Other Items

• XACML Profile - no update. Please review

Actions

• AlexB - revive the use case doc
• Atul - create proposal of MCP profile
• AlexO - split up the certification spec into core and core+
• DavidB - spec-ify the XACML profile