Attendees

• Alex Olivier (Cerbos)
• Alex Babeanu (Indykite)
• Karl McGuinness
• Ken Carpenter (Foundation Devices)
• Vladi Berger
• Braden Groom (Reddit)
• Rahul Raj (T-Mobile)
• John Jiang
• Jeff Lombardo (AWS)
• Alex Henninger
• Debayan Basu
• Edmund Jay

Agenda

1. ARAP (see attached presentation)

   • Priority:
     • Optional signing capabilities (1)
     • Preserve and compare the actor
     • Re-evaluation context and codes
   • Additional points if time allows

2. Certification

   • https://github.com/openid/authzen/issues?q=is%3Aissue+state%3Aopen+author%3Aewjay

3. IANA Registration policy (TBD)

4. AOB

New Member

Braden Groom - IAM team at Reddit, working on federated AuthZ platform

• Building a platform for other teams to plug into - thinking about the contract between teams and how a third-party vendor could bring their own
• Overlap with AuthZEN is the decision point contract

ARAP

• Presentation
• Goal: Burn down the backlog
  • Figure out what needs WG discussion vs what can go offline
• Stateless vs Stateful (#666, PR #738)
  • Colocated don't need signing deps, independent does
    • Colocated PDP + ARS can pass by ref
    • Independent needs a signed binding token from the PDP that the ARS validates
  • Should these capabilities be in the metadata?
    • Two optional capabilities: Signed Denial Binding (PDP emits, ARS verifies) and Signed Approval State (ARS emits, PDP verifies)
    • Conformance is to the capability - PDP can support one, both or neither
  • IndyKite + Cerbos want stateless
    • Cerbos is a stateless PDP but still wants to support ARAP
  • Go ahead with capabilities based model
• Which identity has to match? (PR #756, #662)
  • Actor work pulled out of core - should be in the OAuth binding @Jeff is working on
  • Rahul: Was looking into this also and how to track tokens
  • Need to clarify the scope of what is in the subject
    • #756: Actor (act claim or chain) stays in the subject so it is part of the binding hash and compared on re-evaluation
    • #662: Formally name subject, submitting principal and authorized task caller and use them in every rule - spec currently uses requester, caller, client interchangeably
    • The two work together, not either/or
  • Ken: This means cant do any delegation?
  • Approval would be bound to the agent being delegated to
  • In case of an MCP binding to an MCP task could be a separate entity to the PEP.
    • eg API gateway as PEP gets deny + task handle, hands off to an async job that polls for completion, gateway replays the request when done
    • How the client <> PEP session is maintained is out of scope
  • ARS gets the binding token from the PDP - what should go into the binding token? Things like timestamps break. How do we define that?
    • Only the "authorization-relevant information" should be bound - volatile members (timestamps, nonces, request IDs) excluded - currently a SHOULD and ambiguous
    • Alex: Could sign the original request and let the PDP decide what goes in - but needs to stay stateless, PDP shouldn't store request history
    • Approval token could carry paths of the approved fields back into the original request for the PDP to compare - but could be a big token
    • PDP still needs fresh context (risk signals etc) to make a fresh decision - that shouldn't invalidate the approval
    • Rahul: Put approval claims (approver, ref, expiry) in the OAuth token - pushback, keep this pure AuthZEN
    • approved_at / approved_until can bound the approval to a time window
  • Look into separating the channels of the fields which are approved
    • Ken: Two sets of context, one bound and one not, PEP puts things in the right bucket
• Re-evaluations (#663, PRs #745, #741, #742, #740)
  • This is linked to above about non-identity context - Karl will work on a channels proposal
  • Split approval_revoked out of approval_expired (#741) - not contentious
    • Expired = past the approval window, revoked = cancelled/superseded
    • AlexO: When would an approval be revoked if it is single use? ARS is a workflow engine - one request in, one approval out
  • Retry/polling caps, clock skew tolerances, next_action handling - lower priority, not discussed in depth
  • Outcome: Signing direction clear, actor/subject seems clear, context needs a full proposal - Karl to come back with it

Certification

• Edmund has broken out the issues in the tracker
  • Mix of spec issues and certification scenario issues
• Need WG input to close them off
• Alex to triage the scenario ones and add a link

IANA Registration

• OpenID going through process to manage an IANA registry for AuthZEN - policy being put together for the OpenID board
• Designated experts will be co-chairs and spec editors
• Obligations on WG to raise new registrations and urgent modifications
• OpenID board can take action on behalf of the WG if needed, and covers ownership if AuthZEN is disbanded
• If you are writing specs that need IANA changes you will be folded into this process
• Link to follow
• No objections

AOB

• IIW in 2 weeks - Alex + Omri + some of the Authenticate crowd attending - TBD whether the call that week goes ahead
• Alex out next week (conference)