Meeting Notes 2026‐10‐16 - openid/authzen GitHub Wiki

Attendees

  • Alex Olivier (Cerbos)
  • Jeff Lombardo (AWS)
  • Rahul Raj (T-Mobile)
  • Atul Tulshibagwale (CrowdStrike)
  • Alex Babeanu (Indykite)
  • Omri Gazitt
  • David Brossard (Axiomatics)
  • Alec Henninger (Red Hat)
  • Edmund Jay
  • Vladi Berger
  • Dave Hyland
  • Roland Baum
  • John Jiang

New Member

  • Rahul Raj - T-Mobile. Cybersecurity / IAM. Already working with AlexO on authz; has use cases he hopes the specs will cover and will contribute.
  • Alec Henninger - Red Hat. Background in Red Hat SSO / Keycloak community, SpiceDB in production. Came to AuthZEN via Stian (Keycloak lead). Team has agreed to help contribute the OAuth profile - working through Slack access + IPR agreement. Interested in token validation at the PDP (last week's discussion).

Agenda

  1. Certification

    • Tested: Cerbos, OPA, Axiomatics; pending: IndyKite.
    • What happens when an attribute is missing?
    • Resolve David’s outstanding issue, confirm remaining sign-offs and agree next steps.

  2. COAZ-MCP

    • Latest MCP spec: PR #735.
    • _meta convention: PR #734.
    • Atul’s review; who to target for the implementor’s draft?

  3. Namespacing for actions in profiles Issue #739

  4. Other spec work

    • Obligations PR #697: address Arjun’s comment.
    • ARAP: walkthrough with Karl, if available; status of the four-part split.
    • Omri’s items: confirm they’re ready to land.

  5. Atul: IANA registration for AuthZEN

  6. Atul: interops and OIDF .well-known

    • Broader AuthZEN interop at Gartner or Identiverse later in 2027; presentation plans for .well-known.

Certification

  • AlexO - Foundation has appetite to get certification shipped and live. Edmund sent 8-9 areas needing clarification (some in spec, some in the test scenarios); Omri has replied by email.
  • DavidB - Axio implementing certification (evaluation + evaluations + well-known only, no search). Team reports all green, but when sending an evaluations call where one combination had a missing required attribute (subject ID / resource ID), it was returning HTTP 200 with decision:false - it should be a 400 - its a malformed request. Either the tests don't cover it, the tests are wrong, or the team ran them wrong.
  • DavidB - interpretation: defaults + each array element should produce a valid evaluation request; if not, 400.
  • Omri - Edmund's 7 issues are genuinely ambiguities in the spec and need to feed into the errata process. Wants each filed as a separate GitHub issue so they can be adjudicated individually.
  • Edmund - will create these as seperate issues so we can tackle
  • David - first isssue raised by Edmund matches David's issue.
  • Omri - intent was always that any malformed request should be a 400 - but phrasing in the spec is not clear.
  • David - section 5 & 6 we don't talk about errors. Section 6 points to section 5 for the model; section 5 says attributes are required but never says what happens if missing. Section 7 has an error section (but covers other error types, not malformed requests). Errors only in transport section (10). Oversight? Should section 6 have wording like section 7?
  • Omri - errors are bound to the transport bindings. Admits section 7 (evaluations API) is poorly written ("I wrote it"). Further ambiguity found while responding to AlexO's issue: evaluations response reads as a superset of evaluation response (implies top-level decision + context), but spec recommends PDP not emit top-level decision and PEP may ignore it - conflicts with the schema, where neither Protobuf nor JSON schema have top-level decision/context.
  • Omri - We should treat the OpenAPI + Proto as the only definitive docs. Never made them normative - need to be adopted so issues can be adjudicated against a machine-readable doc.
  • AlexB - current files in that repo only cover evaluation, not complete. Should be language-agnostic (Protobuf).
  • Omri - Protobuf is the source; OpenAPI JSON is derived from it - isomorphic. Both exist, both informally reviewed and agreed by WG in fall 2025 before final; last updated Jan. "Last known good."
  • AlexO - should move them to the OpenID repo at minimum and bind them to the spec. Will check prior art in other WGs. Also wants regression tests across each document vs the schema/proto to catch drift.
  • AlexO - errata process: already collecting smaller text/formatting fixes into a single draft PR on a working branch. Need to decide what counts as errata vs something more major - will fall out as issues are worked. Not doing a 1.1, definitely not a 2.0. No external deadline; target end of year. Certification can go live any time after now.
  • AlexO - possible snag with IANA registrations affecting spec wording (see IANA below).
  • Omri - invited AlexO as owner of the github.com/authzen org; WG can take ownership of it. AlexO notes the buf page etc. is also reserved there so some shuffling needed.
  • Cerbos has two flavours: full coverage (incl. search) used for testing, and the service one is evaluation, evaluations + metadata.
  • Edmund - Cerbos image now incorporated into certification CI (not pushed to release yet).
  • DavidB - Serj is collecting quotes for an OpenID press release; David + AlexO will provide. Open to anyone else who has run the tests.
  • Actions
    • Edmund create 7 separate issues
    • AlexO start folding agreed fixes into errata working branch
    • AlexO move schema/proto from https://github.com/authzen into OpenID repo, bind to spec as normative; check prior art in other WGs
    • AlexO speak to Gert about https://github.com/authzen
    • AlexO + DavidB provide press release quotes to Serj
    • More PDPs test it

COAZ-MCP

  • AlexO - Two PRs open.
    • #735: mechanical bump to latest MCP spec - MCP is now stateless, dropped invalid IDs, changes around logging. Can land as is.
    • #734: moves the AuthZEN mapping from x-authzen-mapping under inputSchema to the new MCP _meta object. MCP now requires all extensions to sit under _meta, keyed by a domain / reverse-domain URI. authzen/coaz-mcp style key not allowed by their spec.
  • Open question: what should the key/path be? Doesn't appear MCP has a registry (nothing like IANA found); samples seem open-ended. Didn't want to just use openid.net. Want to keep AuthZEN branding in the key (Omri's original point for x-authzen-mapping).
  • Atul - comment on #734: example still references agent in context, which we agreed last week is redundant with a passed token. AlexO will change the example.
  • AlexO - #734 also folds in Atul's client example. Max (MCP WG) asked for more worked, real-use-case reference examples - those sections to be updated.
  • Atul - hasn't done the client example yet; no capacity until ~26th.
  • Jeff - should we land these before the JWT representation work (agreed last week) is done? That will require rework.
  • AlexO - land both PRs now, but don't call it draft 2 until the JWT work is sorted.
  • Atul (in namespacing discussion) - can't tell product team to implement COAZ until ID1; feedback on naming should come post-ID1.
  • Actions
    • AlexO raise issue with MCP WG re: whether the _meta key needs registering / what the URI should be
    • AlexO update #734 example per Atul's comment
    • Atul client example + worked examples (from 26th)
    • Land #735 + #734; hold "draft 2" label until JWT representation lands

Namespacing

  • AlexO - context: OAuth profiles, COAZ, others all define action names. If one PDP serves OAuth, MCP gateway and others with a unified audit log, how do you tell which actions belong to which profile? COAZ uses tools/call (JSON-RPC, slash built in); OAuth drafts use issue:xyz - same intent, different delimiters.
  • Omri - the issue is broader - also resource types, subject types. If we invent a convention how do we handle conflict etc (Roland already found a scope-name collision in the OAuth issuance profile). XML namespaces was for this - was a 'disaster'. Complicated reading it. Was reverted later in XHTML. Leans against.
  • David - agree with omri, SAML had profile-defined names. XACML had also (urn:… identifiers) and hard to read - real implementations all use human-friendly names. Focus on readibilty.
  • AlexB - stateful PDPs are types in the graph - please no colons. Resource types etc. are customer data points, not something the spec can dictate.
  • Jeff - AWS-view means if you namespace you can have action groups based on the path itself. Not a regex as its structured. But format only - not IANA-registered values. Exception: JWT profile types should point at existing IANA registries (e.g. token exchange token types) since those are defined elsewhere.
  • Omri - would require registry etc - too much machinery for a simple spec.
  • Atul - why namespace the value? The field already disambiguates. Alternatively restrict to just action names, prefix with profile name (e.g. coaz).
  • DavidB - if we want to standard identifers its driven by two sources: the PDP/policy structure (would want graph/Cedar flavours) or external specs (e.g. use iss as-is from the token). If AuthZEN is request/response, don't encroach on implementation.
  • Omri - is this a real issue or theoretical? OAuth AS is the PEP for issuance; MCP gateway is the PEP for COAZ - different scenarios, different actors, don't see them composing. A PDP vendor that wants to support multiple should handle it (seperate tenants, separate instances etc).
  • Omri - OAuth issuance profile uses shorthand for IANA URIs due to length - separate issue to raise against that profile.
  • AlexO - lets not have a registry etc but lets have a convention for how we define profile-specific values (delimiters etc) so specs look like they are all from one WG. Omri supports.
  • Actions
    • AlexO - propose informal naming/delimiter convention for profiles on #739

IANA

  • Atul - First time non-IETF submission. AuthZEN final spec envisions a group of AuthZEN registries; IANA said this is the first time a new registry is requested by a non-IETF spec (entries in existing registries have happened). They came back with questions.
  • Atul proposed answers: designated experts = the WG co-chairs (whoever they are at the time); experts can add to registry, removal is more complicated; OIDF Executive Director as escalation path. Needs an OIDF process - Atul raising with Gail on Monday.
  • AlexB - doesn't OIDC have these? Sent by email? (Atul: yes - AlexB to review.)
  • Jeff - they went into an existing registry (e.g. Shared Signals subject types into the RFC subject-ID registry). Not unusual for IANA though - 3GPP, W3C, ISO have registries.
  • Omri - answers are reasonable, respond at face value. Will be copied on the email.
  • Actions
    • Atul discuss with Gail Monday, then send answers to IANA (cc Omri)
    • AlexB review Atul's email

OAuth

  • Omri - First PRs landed as draft (merged a couple of days ago, thanks AlexO for reviews).
  • Opened an issue: strong feedback that the profile should cover the authorize endpoint, not just token - scope will expand.
  • Karl's bot-generated feedback proposes a major restructure of the issuance profile into conformance levels (easy → advanced scenarios). Working through it privately; Omri has offered Karl co-editor (not yet accepted). Bot proposed ~80 PRs - won't be that; will batch into something digestible for the WG.

Extenstions framework (apart of obligations)

  • Omri - document is too expansive - can be more concise. Reads as bot-written; largely lifted from Karl's gist. Core should be: here are the sanctioned ways to extend AuthZEN. Two types: mandatory-to-understand (bootstrap as currently described) and advisory (no bootstrap needed; spec already says ignore what you don't understand). Cut the rest.
  • AlexB - fair. Question about context - it is inconistent between evaluation, evaluations and search responses. Should be possible to have context at top level and detail level in all three. Possibly an errata topic.
  • Omri - prior meeting decided to preserve 1.0 and fit everything within it rather than protocol change; should stay consistent with that unless new data. Take offline.
  • Actions
    • AlexB narrow extensions framework doc
    • Context consistency → agenda next week

AOB

  • Omri - Approached by Rifaat to do an AuthZEN/OAuth session at IETF 127. Also planning to make AuthZEN/OAuth cross-over a core theme at IIW; Yaron Sheffer (OAuth WG) has referenced the issuance profile. Jeff will be at IETF 127 in person (not IIW); Omri likely remote unless fee waiver. Omri to ping organisers.
  • Nobody from the group at Authenticate next week.