Attendees

• Alex Olivier
• Jeff Lombardo
• Vladi Berger
• Ken Carpenter
• Alec Henninger
• Karl McGuinness
• Dave Hyland
• Roland Baum
• Nate Yocom
• Alex Babeanu
• Debayan Basu (Independent)

Agenda

• COAZ-MCP: context.agent trust anchoring: https://github.com/openid/authzen/issues/612

  • Need to decide whether the PEP passes trusted token-derived inputs to the PDP or the PDP gets them itself

• Obligations and Constraints: Bounded Grants: https://github.com/openid/authzen/issues/521

  • Need to decide whether constraints (context.constraints[] plus a type registry) should become a separate companion profile, and what happens to the remaining items: fulfillment tiers and a registered step_up.

• AuthZEN Extensibility Model (Draft 2, proposal) https://gist.github.com/mcguinness/caab9ff46a8b0123cfa84645e9a60a7f

  • Needs to be agreed before obligations can be merged

New Members

• Ken - Foundation hardware root of trust
• Alec - RedHat - ran IAM, contributed to KeyCloak
• Debayan - IAM at Genuine Parts company. Part of GovOps also.

COAZ-MCP: context.agent trust anchoring

• AlexB: How does the PEP pass in the agent details?
  • OAuth token is a requirement of MCP - lets use that and not require anything else in the context
  • Some policy engines are using token claims as policy attributes
  • This is profile for MCP, doesn't do anything to the base spec. The token requirement would be just in the MCP profile.
• Karl: We are missing a profile for how to represent OAuth entites in a standard AuthZEN message. Actor chain, implicit, explicit etc. MCP would just be one binding to that.
  • As OAuth extensions get added it could naturally be adopted.
• Jeff: This was tried at the beginning of AuthZEN. What would be the type of the subject if it is JWT?
• Karl: Ask is to pull out that part into its own spec

Decision: don't merge the PR and land profile as is and then work on the OAuth binding as a document other specs can reference.

Obligations and Constraints: Bounded Grants

• AlexB: https://github.com/openid/authzen/pull/697 is ready to merge

• Karl: Naming of the obligations profile - it feels like the default registry. Name doesn't align now. Are they core/inital?

• AlexO: We need to package and schema for new/custom obligations.

• Jeff: Recommend registering IANA types for these.

• AlexB: will update PR

AuthZEN Extensibility Model (Draft 2, proposal)

AlexB will take it over and merge in so other specs can point to it.

## AOB

• Karl: Decisions models (eg Jev) need a differnt interface for speculative evaluation rather than partial. Dont want side-effects to be triggered, audit trials etc.

  • https://gist.github.com/mcguinness/6969cb4cf067fb784bb88d038b0e8d8a
  • AlexO: also need it for UI use cases

• Alec

  • Interested in having the PDP recieve an OAuth token and have it handle the validation, token claim mapping etc
  • AlexB: the core spec is agnostic of that.
  • Karl: Seperation of concerns. The PEP does token signature. Claims/issue trust can be in PDP.
  • AWS, Cerbos, IndyKite all do the token validation today
  • Jeff: Profiling passing the token as a subject. Who is writing that?
  • Alec: Looking to centrlizing the validation of the token. If every PEP is responsible for validating then each PEP would need updating if something changes. PDP and isser can be neatly integrated instead.
  • Alec: There are two things in the spec - trust section talks the other way. Where would the token fit etc.
  • Jeff: Willing to take the lead on the draft for OAuth token mapping profile

• New specs in workload authorization can help