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

Meeting Notes - 2026-07-30

Attendees

  • Alex Babeanu
  • Omri
  • John Jiang
  • Roland Baum
  • Karl MacGuiness
  • Atuil Tulshibagwale
  • Julio Auto De Medeiros
  • Dave Hyland

Agenda

  • (AlexB) Obligations

Notes

  • [Omri] What's the relationship between obligations and Filters and Partial Eval.
  • Clarification: Obligations are not partial evaluation/parse tree
  • [John] possible use case: Human approval, 2FA: the PDP
  • [Omri] Filters: Fwk that can be enhanced. Additional Obligations later? ]
  • [Karl] Need invariants for profiles, in the base. E.g., bi-directional negotiation is mandatory.
  • [Omri] How to register the decision subject across profiles. STandardize set of claims? Prior art: Vittorio's JWT claims.
  • [Karl] When should there be namespace/non-namespace claims/properties. When to register common/non-common properties: extensibility, need a registry. See JWT, clauses for how to ensure uniqueness for custom claims.
  • [Omri] Need to follow-up on actually registering the AuthZEN params with IANA.
  • [Atul] We only added values to existing registeries. Not sure what the process is to create a new registry. May need a special ietf spec.
  • [Karl] why not use the openid registry. Define SARC as a Media type. E.g., authzen.eval... type_name = "authzen/sarc/...". As an option: other openid specs are defined as media types.
  • [Omri] AuthZEN 1.0 describes in detail what needs to be registered. ACTION ITEM for the group: do the actual registration.
  • [Omri / Karl] Layout the basics of how to build an obligation, unbundle from the lifecycle. Notify could be separate, may need its own iterations. Each obligation is separate and "just" needs to comply to the base rules.
  • [Atul] Shouldn't obligations be its own core/base spec rather than a profile? They are core to the base specs. Obligations are not specific to an application area or domain, they're generic.
  • [Omri] What's the diff between a core vs profile spec? Need to dwefine criteria.
  • [Karl] +1 about thinking more about protocol and defining vocabulary. Profiles are constraints around the primitives. How do we brak-down verbs, remediations? Need meta-protocol considerations...
  • [Omri] ARAP extends the protocol surface, hence should be a core spec. Partial Eval should be a protocol, as it requires new APIs, etc. Obligations just extends the context + a negotiation flow, true. Could go either way.
  • [Atul] Extensions. ARAP + Obligations can be considered extensions. MCP binding is a profile, the others are generic.
  • [Omri] Defining a metadata layere, is a complement.
  • [Atul] ARA & Obligations are 2 facets of the same concern. ARAP + Obligations ca be core specs.
  • [Omri] Obligation can be termed a "Profile". Different styles of remediation.
  • [John] Agreed it cannot be combined with obligations.
  • [Atul] ok to keep them separate
  • [Omri] "Extension" instead of "profile". Extension = Add protocol surface. Optional to Implement. Can be added to metadata. More than a profile. "Obligations" can be an extension, because it adds constraints to the PEP.
  • [Karl] Gaps: handshakes, fail open/close, need a well defined negotiation.
  • [Omri] How does the PDP discover smthg that the PEP supports. That part was never formalized, needs ot be done in a core spec. Other "things' can take advantage of this. "Bi-directional negotiation" - Obligation being a profile of that.
  • [Karl] Client capabilities flags -> base layer. Precendents on HTTP (header). + PEP Identity: no guidance. WHat is client Identity ? Public key of the PEP? Identity + credentials. Is it an hint? No need to authN? Client capabilties, do they need to be signed?