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

Meeting Notes - 2026-05-14

Attendees

  • Alex Olivier
  • Karl McGuinness
  • Gert Drapers
  • Omri
  • Vladi
  • Julio
  • John Jiang

Karl - Access Request & Approval Profile

  • Omri: Advice & Obligation spec was very broad, Karls proposal is a more concrete, practical profile.
  • Gert: Assumption this is a profile? Do we have a mechanism for discovery of those yet.
  • Omri: Via the discovery endpoint in the v1 spec
  • Karl: Assume extensibilty mechanisms will be codified as more profiles exist. Not trying to solve for that for now.
  • Karl: Shifting for evaluation to governance. You can't predefined access in a policy. Been working on mission oauth. Learn over course of the mission to govern that and handle scope increase/decrease over time.
  • Karl: Every app needs an access request flow eg Google Doc email. There isn't a standard way to do this. Would be good to have a standard way to discover those. Don't want everyone doing back channel flows. Prefer to funnel that through a centalized authz decision.
  • Karl: A deny should be able to provide a redemdation step also. Important with agents access multiple resource services.
  • Going to keep pushing forward with or without AuthZEN support as the standard.

Karl ran through: https://mcguinness.github.io/draft-mcguinness-authzen-access-request/draft-mcguinness-authzen-access-request.html

Questions:

  • AlexO: Is the approval system standalone or in PDP?
    • Could be legacy IGA etc - not coupled.
  • Omri: Is the goal of the re-approval flow to create the correlated audit request cycle?
    • Yes, audit is key part of this. Link the eval-deny, approval, eval-allow steps together.
  • Omri: Today AuthZEN evals are stateless - does this change that?
    • Yes, its a new mechanism on top. Opt-in.
    • Omri: Could use the corelation ID in the spec already
  • Gert: In this flow, where is the correaltion ID being minted?
    • In step 2, returned back from the PDP
  • Gert: What is the possible life of the request?
    • TBD how the access request server would express this. Would be driven by the type of request it is.
  • Gert: Who owns the evaluation ID?
    • The PDP would return it, along with a serialized request. The PDP would submit the request to the approval system, which returns the ID etc.
  • Omri: The approval_until pattern - could this be a jwt? Like tokenetes?
  • Gert: If this is the approval, how do you know where to route it? How do we have the trust chain? ID is a jwt?
    • Thats an option. Do we want to bind the evaluation ID?
  • Gert: How do you ensure this is a continuation of another evalution? If it distributed, how do you know where to go next?
    • There maybe some properties around binding which may need to get strenghten
    • For distrubtion, the actors are fixed. The evaluation is bound to the PDP. The approval came from the evaluation ID, with the context, bound to that PDP. The re-evaluation has to be done back to the original PDP as they are bound.

The deny remediation use case looks more like advice than obligations in the XACML model. There maybe a different mechanism for obligations (a lot harder).