Meeting Notes 2026‐06 04

Meeting Notes — 2026-06-04

Attendees

• Alex Olivier
• Alex Babeanu
• Gert Drapers
• Patrick Parker
• Mike Kiser
• David Brossard
• Edmund Jay
• Michiel Trimpe
• Julio Auto De Medeiros
• Anishma Mavuram
• Karl McGuinness
• Roland Baum

Agenda

• Advice/Obligations
  • Review updated proposal from AlexB
• Access Review Profile draft
  • Karl's proposal has been adopted as a working group draft
• Define a roadmap, in particular for:
  • COAZ Profile
    • Outstanding issues
    • Relation to Patrick Parker's Contract-Driven Autonomy proposal
  • Policy Store proposal from Mike Schwartz
  • Partial Evaluation
• Certification update
• Upcoming events
  • Identiverse AuthZ Masterclass — Monday

Programming note

• Karl
  • Getting some PRs in place for Access Request
  • access-request GitHub issue label
  • Okta, SailPoint, Axiomatics and Cerbos interested in getting involved
  • Reached out to arms.dev (?); also proposes reaching out to MCP. Wants an end-to-end approach and to move fast.

Patrick Parker's Contract-Driven Autonomy

Shared presented material: https://drive.google.com/drive/folders/1fQmEkrLhxI0Uexvvqp8gMnNquqzr528a

• Contract-Defined Automation. Uses AuthZEN for agents, mainly those using MCP tools.
• Goal is to use the tool metadata to provide context for authz.
• Uses the context in the AuthZEN call to provide useful information for the agent orchestrator.
• Annotate the tool with x- metadata.
• Giving an agent a true/false decision is not enough to stop the agent hallucinating. Need to give it more context on what to do, e.g. obligations or constraints.
• Questions
  • AlexB/AlexO — OperationRef vs ToolID: why do we need both?
  • Karl — A lot of overlap with the Access Request spec for solving the remediation paths. Not clear how much is behind the MCP layer and what needs to be in the MCP client. Need to be clear between the OAuth layer, the MCP layer and what's behind that.
    • Some of the metadata is consumed by the PEP. The tool schema can pass richer information to the PDP.
    • The policy engine says yes/no, but also gives back guidance.
  • AlexB — Overlaps with obligations, but that's a wider scope — things like step-up.
  • Gert — How much does this rely on obligations? Constraints and obligations are not the same thing.
  • AlexB — The PEP needs to know what to do with the obligations.
    • The PEP needs to opt in to understand it. The policies need to know.
  • Karl — Recommend sharing the metadata with the MCP working group, as there is a lot of work going on around the tool metadata layer.
    • Need to tie in the MCP layer to understand what comes from the policy layer.
    • MCP needs the extensibility point — OIDF should own the enterprise profiling and get it pushed more into the MCP spec.
  • DavidB — We should follow the layering of profiles.

Advice/Obligations

• AlexB
  • Still not clear if we want to do this.
  • Having pre-canned obligations is a nice pattern.
• DavidB
  • We need to take the lessons learned from XACML. If the PEP can't be trusted, then you shouldn't trust the decision either.
  • Less than half of Axiomatics deployments use obligations.
  • The spec can only really cover core obligations like MFA and identity-related ones.
• Karl
  • Didn't go down the route of modeling access request as advice/obligation — hard to model an obligation as a denial.
  • Could be implemented as just advice as metadata.
  • MFA use case is tricky, as it should be a denial with a requirement to step up.
• DavidB — In XACML land it didn't talk about the modeling. We need to agree on one path.
• Gert — This is constraints over obligations. Where is the responsibility, and who respects what? Returning it as a constraint is a reliable and consistent approach.
• Julio — There was an earlier proposal to have a negotiation protocol — is that still happening? Only if we are doing obligations.
• Patrick — A constraint reduces the authz; an obligation is something else. Need cases like human-in-the-loop for agents too.
• Karl — Need to clearly define the roles (PEP, Access Request service, etc.). The role decouples the components. A single approval layer could handle many PDPs.
• Next steps
  • AlexB — Document the use cases discussed.
  • AlexB — Need clarity between constraints, advice and obligations.

Zoom comments

• John — An obligation may be the job of a PIP or something, but not the PDP. An obligation may be a policy, but not an authorization policy.
• John — Another view is that an obligation is a policy where the PDP cannot determine whether it is satisfied. In such a case, the PDP should return it to the requester in a partial evaluation response, which includes all the remaining policies for which the PDP has no decision.

AOB

• DavidB — Proposing moving the call back.