Meeting Notes 2026‐07 02 - openid/authzen GitHub Wiki

Meeting Notes - 2026-07-02

Attendees

  • Alex Olivier
  • Alex Babeanu
  • Omri Gazitt
  • Gert Drapers
  • John Jiang
  • Michiel Trimpe
  • Dave Hyland

Agenda

Notes

Process note: Chairs working on process guidence & Roadmap for 2026H2 to make it clear how the open proposals (Policy Store, AARP, AROP)

Advice & Obligations

  • AlexB: Don't want to call it A&O. Proposing a name change to remediations? Challenges (too confusing with OAuth?)? Hints? Directives? It answers here is a DENY, and here is what is needed to get a different answer.
  • Dave: Banks have adaopted the term challenges - but that is an OAuth context
  • Omri: There is a difference between DENY context and ALLOW context. Those could be words we use which denotes different structure. The protocol depends on how trusted the PDP and the PEP is
  • AlexB: This would be within the context element.
  • Omri: The profile is about defining the ALLOW or DENY context
  • Gert: Does AuthZEN want to be explicit about the fail open vs fail close. That is at the bottom of this. I always reason from fail close.
  • Omri: There is enough practioners that need the obligation style.
  • Gert: That means it needs to be discoverable and negogiation
  • Omri: The advice part doesn't need as strongly enforced as obligations. The PDP should always sends a DENY if the PEP doesn't support obligations. The PDP can always send more context.
  • Michiel: PERMIT/DENY doesn't work in this context. Its a DENY_WITH_LIMITATIONS type thing. In the API Gateway use case the PDP could return an obligation to strip a header
  • Omri: Permit but filter use case - PEP to apply some post filtering to a result set.
  • Michiel: A gvt standard, the ideal case you reject and the app layer applies some filters - but that isn't possible in all cases - so return the filters to apply as an obligation at the gateway layer
  • Omri: Gravitate to zero trust and fail close
  • Gert: Worried about from an open protocol perspective how to deal with getting to the same outcomes if you swap out the PDP.
  • Michiel: basic negogitation should cover it. PEP would send in the request with supported limitations, PDP receieves that then the PDP can return the limitations that are supported or else fail close.
  • Omri: The PEP before sending the feilds can also find it via discovery endpoint. We do have a stateless negogitation capability here.
  • AlexB: Still hear limitation and remediations as the terms. Use cases so far step up, HITL, filter criteria
  • Michiel: Styra has a content-type like vnd/json-ucast which the PEP needs to support or not.
  • Omri: Need two negogitation and have a registry of things that are obligations/remediations in addition to knowing if the PDP support this capabilty. It would be useful to know what the PEP supports also. There maybe some custom ones which the PEP and PDP know about but for there to be introp value there needs to be specific obligations that PEPs need to know about.
  • AlexB: 3 terms:
    • Obligation - something a PEP MUST DO
    • Remediations - DENY but you can remediate it by doing XYZ
    • Limitations - ALLOW but here are the limitations
    • Out of scope Advice - that is the context for anyone to do as they wish
  • Dave: We say 'things we want the PEP to do' - do we ever go as far as telling the client what it needs to do?
  • Omri: Assumption there is a front channel to a user
  • AlexB: Not really our concern as written today - its beyond the PEP.
  • Dave: Are we using language/syntax which is for the PEP to consume or the system which concerns the PEP?
  • Omri: We use PEP term throughout as PEP==Client. The invoker of the protocol
  • Dave: The PEP assumes the context of the client. The PEP needs to translate that back to the client.
  • Michiel: terms so far
    • Permit -> limitation (MUST be supported and honored by the PEP)
    • Deny -> remediation
  • Omri: We can't always assume the PEP has a front channel to the user eg to force a step up. There needs to be something to relay it via some method to the client to enforce the conditon
  • Dave: Have been doing cases with fail open - like risk base control - cases when the risk engine fails don't want to block the payment.
  • Michiel: A DENY with an obligation doesn't seem right
  • AlexB: The PEP must deny the request regardless if its a deny.
  • Michiel: The context is open on purpose.
  • Omri: These should be profiles - can't change the 1.0 spec.
  • Omri: Note that David @ Axiomatics & Vladi @ PlainID have more use cases that need to be folded in.
  • Omri: Karl's ARC effort is about how to handle the remedation process under a fail cose. Do we want to have an effort in the other direction - a profile which takes the opposite, you can fail open but the PEP must do a set of things for the action to be permited.
  • AlexB: Have implemented advice in IndyKite for step use case.
  • Michiel: Step up is a remediation.
  • Michiel: It is more than one profile - different processing models
  • John: Limitations, remediations, obligations etc there be more scenarios which can be defined by policy - rather than adding them to the protocl, is it better to put into a standard policy spec? Return the remaining policy to PEP. What we are doing is a distributed authz system - and we are the protocol.
  • Omri: Restated - there are a class of AuthZ system which never return a PERMIT/DENY rather come back with a partial evaluation - there is some expression tree which gets returned. When the PEP processes the response will take that and apply some filter or such. Advice/Obligations are tied to partial evaluation.
  • Omri: Disagree that the response should be more structued. We need to cover lots of different types of PDP - which we've achieved. But there are a set of scenarios like step-up, advice etc are narrow use cases which we can express crisply. Partial eval has a role, but not sure how to make that interopable.
  • Next steps
    • Vested parties come up with a proposal to present to the WG to decide to bring into workign drafts
    • Likely two profiles
      • Michiel, David, Valdi case
      • AlexB case

Chat comments

John Jiang (2 Jul 2026, 21:13) To me, all these are what the remaining policies that the PEP is yet to satisfy -- the PEP has satisfied part of the complete set of policies. Giving back the remaining policies to be satisfied is the job of a partial evaluation in my mind. Mandatory, advisory, and optional are attributes to the particular policies and should be specified by the policies instead of by the protocol.

Michiel Trimpe (2 Jul 2026, 21:29) For the record; terms so far: Permit -> limitation (MUST be supported and honored by the PEP) Deny -> remediation

John Jiang (2 Jul 2026, 21:39) There are a lot of more scenarios than limitation, remediation and obligation. Instead of expanding the protocol, it'd be better to define a standard policy specification language so that all these scenarios can be specified by policies. A PDP can respond to PEP with the remaining set of (partial) policies.

Dave Hyland (2 Jul 2026, 21:58) Will need to read Karl’s doc properly but we’ll need to be able to support fail open… must have for any risk based assessment, or pdp flows that support friction based policy