Meeting Notes 2026‐05‐28 - openid/authzen GitHub Wiki

Meeting Notes - 2026-05-28

Attendees

  • Gert Drapers
  • John Jiang
  • Atul Tulshibagwale
  • Vladi Berger
  • Omri Gazitt
  • Debayan Basu
  • Edmund Jay
  • Mark Berg
  • Vatsal Gupta
  • Ilias Borsas
  • Aniruddha Bildikar
  • Karl McGuiness (very late)

Agenda

  • EIC recap?
  • Vote on Karl's profile
  • Obligations:
    • How do deal with Boxcarred obligations?
    • Can we have obligations on Searches?

Notes

Karl's proposal:

  • [Omri] Karl's an Architect at Okta. As an independent he tries to fill-in several gaps: AI/Agentic + OAuth. He got reminded of AuthZEN at IIW. "How does an agent interact with a PDP?". He realized that remediating a "Deny" requires a protocol, to end-up with a "Permit". More like an Advices. It's complementary to Obligations work.
  • [Gert] 1) This makes the PDP more stateful. Must be acknowledged. 2) the Trust relationship, how can we ensure the responses are secure and not spoofable? The current proposal doesn't resolve that. But agrees with the proposal.
  • [John] 1) The use-case is relevant and needed 2) But making PDP stateful is a can of worms, and dangerous. 3) Partial Evals can address most of the use-cases. The Decision Context == conditions or partial policies that must be satisfied. -> Partial evals should be used instead.
  • [Gert] Partial eval is more of an implementation concern. Statefulness is indeed tricky, better to not be if possible.
  • [John] "my partial eval is different than David's." The response is a response to the evaulation of all the policies. Everything return, obligations, etc... are an unmet set of policies.
  • [ Omri] AuthZEN is Stateless, which is valuable. Karl is not changing the semantics. "Continuation Protocol" is encapsulated by a different role. BUT the PDP needs to know about it (about the "ARS"). Partial Eval. is not the mechanism to solve all these problems. Partial Eval is a query plan, should not be combined.
  • [Alex] it seems to me important to know that a re-eval requested follows an initial attempt.
  • [Gert] It's a continuation protocol. The evaluation_id is just provided for auditing, or continuity, not necessarily full state.
  • [Omri] Initial thought: the PDP shouldn't retain state or anything. Any responses from PDP doesn't take into account any past event or state. The Original PDP that issued the response must be the same that re-evaluates it, this part is a bit stateful.
  • [John] If the ID is not to be used, can we just removed it?
  • [Gert] if you can prove that the ID is provided by the right PDP (using signatures) that would be useful.
  • [John] where to record issues?
  • [Omri] Karl said ok to move the profile to the AuthZEN repo. Sometimes better to record issues, in other cases send messages to dlist.
  • [Vatsal] What is the difference between a Standard and a Profile? What decides ?
  • [Alex] Profile is an addition to a base spec.
  • [Omri] The line can be blurry. But adding more to the core base document that the spec is not complete yet. Don't want to send the wrong message and kill adoption: need to project stability. A profile is a document that describes how to use the base spec in a particular situation. E.g., "how does authzen work with MCP?". Some profiles may become part of the base spec in later versions.

Obligations:

  • Alex's questions
  • [Gert] Current mechanism : Default context for all
  • [Omri] Looking at spec - the context is per decision. No request-wide context as per spec. Obligations per request. It may be enough to have 1 single obligation for the whole set.
  • [Omri] Obligations is a brittle mechanism. PEP + PDP must advertise that they support it, must be negotiated. Each obligation is a contract, both need to know what the contract means. Step-up has value. Replacing by "Advice" makes things easier. Obligations require the PDP to really trust the PEP to perform.
  • [Gert] Step-up is just an advice. "You'll get the data" if you do this... I.e., the PEP doesn't have to do it.
  • [John] Are AuthZEN Searches secure?
  • [Gert / Alex] depends on the policies

Next Steps

  • Obligations: There are some concerns about whether obligations are needed at all, given the amount of trust required between PEP and PDP. Are there scenarios that really require Obligations specifically? Advices seem much more appropriate, as losely-couples the PEP and PDP. --> Discuss with group next week to decide whether we need an obligations mechanism/profile at all.

  • Karl's proposal: the group decided to bring-in the profile, add it to the AuthZEN repo and start capturing and tracking issues and discussion. @AlexOlivier, had you volunteered for that task?