Meeting Notes 2026‐04 23 - openid/authzen GitHub Wiki

Meeting Notes 2026-04-23

Attendees

  • Alex Olivier
  • Omri
  • Atul Tulshibagwale (CrowdStrike)
  • David B
  • Julio
  • Edmund Jay
  • Anishma Mavuram
  • Mark Berg
  • John Jiang

Agenda

Notes

MCP Issues

  • Atul - Looked through all comments from Dan - no additional issues
  • How to represent both agent OBO human and agent OBO itself in COAZ mapping
    • Atul: need to model when an agent is running without a user context
    • Atul: How do we handle this in COAZ? Do we require a particular type? How do we seperate the user vs the agent identity?
    • Atul: We need to have a way to standardize what goes where in the AuthZEN call. We could use the subject type as agent, and then the context could have the other identity.
    • Omri: If the subject type is always identity, then could use the property of the subject or something in the context if needed. Nice thing to harmonize on a single subject type where possible now.
    • DavidB: Could use a structued value identity.agent or identity.user etc
    • Omri: Still need a default mapping
    • AlexO: The token should/may have both identities? Can the PDP just look at that?
    • Atul: Still be cases where you may need to handle multiple
    • David: There could be many identites involved. Need to convey all subject data. ID and type is meant to be the actor doing the action. And put the rest of the identity chain in the context.
    • Omri: Use cases - world today is OAuth delegation. Type of policy expected to write is subject is the user with an agent on-behalf - but the agent is not the subject as David is the one with the permissions. Need to be able to write a policy to use that as deciding factor.
    • Atul: Nebulous notion of who is the actor.
    • DavidB: When doing delegation use case - you either need to rework the policy or the PIP based on the request. CPA being given authority to do your taxes.
    • Atul: Don't agree with the notion that an identity is always the user.
    • Omri: Need a defined convention for the default mappings.
    • Atul: Whatever the model is, need to make sure it works for 'users' regardless of the MCP or not
    • Omri: jwt.sub should be the subject.id and subject.type = 'identity' then its a standard partner. World works of OAuth - we should leverage those conventions and then overlay agentic conventions as they emerge.
    • Atul: Maybe we evolve the spec to be more perscriptive around the token mapping and type.
    • Julio: Worry about being too perscriptive when there is so much flux around agent identity right now.
    • Atul: Balance we need strike is PDP complexity and not restrictive to limit future iteration.
    • Omri: Need to add the higher level layering still.
  • Explaining with COAZ is needed
    • Omri: Same pattern for MCP could apply to OpenAPI spec for example. Exposing metadata for how to do AuthZ similiarlly for AuthN today.
    • Omri: Common concepts we can define eg reaching into a payload and parsing data with CEL which work with many bindings JSDoc, Swagger etc
    • David: I agree. Scanable metadata could lead to policy defintion also.
    • Omri: COAZ as a pattern should be thought of holistically. Write the document to explain all this and make it easier for other communities to adopt.
    • Atul: Definitely the direction eg AlexB wanted to map to A2A calls. If we broaden it too much now we could loose utility in this concept.
    • Omri: Don't want to boil the ocean, comprimise the ergonmics. Trying to point out there is an opportunity for AuthZEN to fit into metadata formats eg declare authZ intent.
    • Julio: I think this is useful - two things. 1) am i informing you can make authzen requests 2) these are the requests I am going to make
    • David: The API Gateway profile was hitting the same issues. We need to do two things
      1. technical plumbing profile eg mcp message
      2. application profile eg user in salesforce
    • Omri: Broader problem is mapping from an info model to the AuthZEN model.
    • David: Could work on the business model eg goto HL7 or the technical path like MCP.
    • Atul: This mapping is for the PEP - need to present this mapping to whatever the PEP will be.
    • Omri: By providing the mapping, the PEP logic can be decoupled
    • AlexO: Mapping structure is generic
      • default mapping and inputs to CEL is only variant
  • Naming of the key
    • Omri: We have brand arond AuthZEN we should use it. eg x-authzen-mapping
    • Atul: x-authzen-mapping not sure if that solves the problem, might do. Are we communicating it the wrong way around.
    • AuthZEN is always the target.
    • David: If we follow others it is XXX Profile of OpenID Connect eg MCP Profile of AuthZEN
    • Atul: Need a name for the mapping structure. MCP Mapping for AuthZEN is better.
  • "@" in CEL expr

Certification update

  • Edmund - Have all scenarios all setup now. Working with the interop instance. Working on final payloads for the certification portal. Will have a demo ready soon.
  • AlexO - Need to name the tiers

Conferences

### Action

  • AlexO - sent Omri slides for AuthZ