Dear Hannes and Rifaat, I would like to request a 15-minute slot in the joint WIMSE/OAuth session at IETF 127 for a discussion topic:
Title: Authenticated Is Not Authorized: Delegated Authority Across Workload and Agent Boundaries Speaker: Arjun Garg (independent contributor; Senior Staff Engineer, Intuit — speaking in a personal capacity) Abstract: Agent and workload systems increasingly carry authenticated identities across protocol boundaries, but authentication alone does not establish the effective authority that should survive each handoff. This agenda item connects current public work across WIMSE, OAuth/AuthZEN and agent protocols: distinguishing acting workload identity from delegated user authority, preserving authority through protocol translation, and testing when downstream execution exceeds what was authorized upstream. Using public WIMSE review work, AuthZEN's decided PEP-to-PDP trust position (Oct 8 WG decision: the PDP reasons over validated token claims; no binding-defined trust-anchored context.agent — see below), and executable A2A-to-MCP authority-boundary cases, the session would identify where existing OAuth artifacts already carry the needed evidence, where profiles need clearer binding rules, and which questions belong in joint WIMSE/OAuth work rather than agent-specific extensions. Format: Discussion-oriented (no new Internet-Draft; see below). I will bring slides. Supporting public work (all verifiable, no new draft needed): - WIMSE architecture, PR #140 — "Clarify identity requirements for AI intermediaries" (ietf-wg-wimse/draft-ietf-wimse-arch#140): filed at the issue author's explicit invitation; open and unmerged, reviewed with an APPROVED review from the issue author (szh) on Sep 29 after one changes-requested round. https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/pull/140 - AuthZEN issue #612 — "Should context.agent be trust-anchored when derived from the validated token?" (openid/authzen#612): CLOSED Oct 8, 2026 after the WG reached a decision on its weekly call (Model A, per baboulebou): COAZ-MCP will not define a trust-anchored context.agent field. Policies needing acting-client or actor identity reason over the validated token's claims (client_id, act, issuer-profile claims), not a binding-defined field. The broader gap — no standard way to map OAuth entities (represented subject, client as principal, current delegated actor, actor chains) into the AuthZEN model — moves to a separate OAuth mapping profile that COAZ-MCP, the token issuance/exchange profiles, and ARAP can all build on; identitymonk agreed to lead that draft, and I am invited to contribute the negative tests and spoofing vectors. https://github.com/openid/authzen/issues/612 - AuthZEN draft PR #667 — "COAZ-MCP: define trusted acting-agent context" (openid/authzen#667): CLOSED unmerged Oct 8, 2026 in line with the #612 decision; its negative tests and spoofing vectors are to be carried over to the planned OAuth mapping profile. https://github.com/openid/authzen/pull/667 - Note to [email protected] on delegated-authority continuity (Sep 17). Discussion of OAuth fine-grained authorization on the list. - Executable authority-boundary cases: public A2A lost-response reproduction (arjun2075/a2a-lost-response-repro, posted to the A2A #1987 conformance discussion) and A2A→MCP authority-boundary conformance fixtures. https://github.com/arjun2075/a2a-lost-response-repro This connects directly to the OAuth charter's "Complex Delegation" work item (authorization of automated agents working on behalf of users, including across administrative domains) and to the chartered OAuth↔WIMSE coordination on multi-hop workload identities (Token Exchange, DPoP). Attendance: I am local to the Bay Area and can present in person Nov 14–16, or remotely for a session later in the week (I travel internationally on Nov 17). Happy to adjust the slot length or fold this into a related discussion if the chairs prefer. Best regards, Arjun Garg _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
