Hi Kieran, Thanks for your interest. However, I think the authorization delegation chain composition is out of scope for this work. However, you are right that it might be interesting to consider other mechanisms than oauth. However, I don’t think the charter say anything different. Yes, we do mention oauth as this is an IETF technology but I think the auditing architecture should also be applicable to other authorization mechanisms.
Mirja > On 21. May 2026, at 03:54, Kieran Sweeney <[email protected]> wrote: > > Hi Mirja, Henk, > > Thanks for the architecture draft and proposed charter. Sharing a use case > from outside the enterprise/workload space that the current scoping doesn’t > fully address. > > I’m building Cred (Cred dot ninja), a credential delegation primitive for > this shape of deployment. > > Consider a deployment where a consumer authorizes an agent to act on their > behalf across a portfolio of retail sites (Shopify-powered DTC, eBay, StockX, > marketplace platforms, etc.). The retailer doesn’t see the delegation layer > unless they audit signatures. > > Two observations: > > 1. The user-to-operator audit gap is more pronounced for consumer agents than > enterprise ones. > > - The bridging artifact (what survives the session and proves the link) needs > to work even when the downstream resource has no OAuth Authorization Server > and the only auth surface is a session cookie. > > 2. The downstream resource posture varies more than the charter currently > anticipates. > > - Agents acting on behalf of users will hit a spectrum of resource auth > shapes. The audit machinery the charter proposes works cleanly for the full > OAuth AS but it needs to compose with non-OAuth resources for the long tail > to be covered. > > I’d find it useful if the charter scope included: > > - A receipt/evidence format that binds to action payloads independently of > whether the downstream resource speaks OAuth > > - Guidance on how delegation chains compose when one or more hops use > non-OAuth auth (cookies, API keys, bespoke session tokens) > > Best, > > Kieran Sweeney > > Principal Engineer > cred.ninja > > > On Wed, May 20, 2026 at 8:13 AM Mirja Kuehlewind (IETF) > <[email protected] > <mailto:[email protected]>> wrote: >> Hi wimse group! >> >> We proposed a new potential BoF on auditing (for AI agents mainly) on the >> agent2agent mailing list (see below). >> >> The proposed work could use or would potentially benefit from use of wimse >> identifiers. Therefore we thought this group might be interested in this >> work! >> >> Mirja & Henk >> >> ———————— >> Here is also the proposed charter text directly (for more details checkout >> the architecture draft linked below!): >> >> # Agent Use of Delegation and Interaction Traceability (AUDIT) Working Group >> Charter >> >> Autonomous and semi-autonomous software agents, including those based on >> artificial intelligence (AI), are increasingly deployed to act on behalf of >> users, organizations, and services across the Internet. These agents >> interact across multiple administrative or trust domains and can initiate >> actions without direct human oversight at each step. >> >> This introduces challenges for auditability, accountability, and >> transparency, including: >> >> * Difficulty attributing actions to a specific user, agent instance, or >> delegation context >> * Loss of visibility across long-running or distributed workflows >> * Inconsistent capture of delegation relationships, authorization context, >> and identity transitions >> * Cross-domain interactions lack interoperable means to exchange or verify >> audit-relevant information about the participating agents and their >> interactions >> >> AI agents participate in two distinct classes of interactions that must be >> audited: >> >> * User-facing interactions, such as prompts, conversations, and approvals, >> capturing user intent and human-in-the-loop decisions >> * System-facing interactions, such as API calls, tool usage, and delegation >> to other agents or services >> >> Effective auditing requires linking user intent to resulting system actions >> across protocol and administrative boundaries. While traditional workflows >> support evolving authorization, these transitions are usually explicit and >> predefined. AI agent systems introduce dynamic, fine-grained authorization >> changes that arise during execution, driven by agent decisions, delegation, >> and human interaction. Auditing must therefore capture authorization as a >> time-evolving state and correlate these transitions across interactions and >> domains. >> >> Additionally, AI agent behavior may be non-deterministic and not fully >> predefined, requiring auditing mechanisms to capture execution context and >> structure as they emerge. Auditing must also distinguish between user, >> agent, and service identities, and ensure audit data remains interpretable >> across systems without shared assumptions. >> >> ## Scope and Goals >> >> The AUDIT working group will define interoperable mechanisms for auditing >> and accountability of AI agents and delegated systems across Internet >> protocols. >> >> The group will focus on architectures, protocol-layer specifications, and >> data representations that enable systems to record, exchange, and verify >> audit-relevant information across user-facing and system-facing >> interactions. This includes capturing delegation chains, evolving >> authorization state, and enabling consistent interpretation and correlation >> of audit data across domains. >> >> The working group will not define auditing policies or compliance >> frameworks, but instead provide the technical building blocks needed to >> support them. >> >> ## Deliverables >> >> The AUDIT working group is expected to produce: >> >> 1. Architecture for AI Agent Auditing >> An Informational RFC describing roles, trust relationships, and data flows >> for interoperable auditing, including the relationship between user-facing >> and system-facing audit signals. >> >> 2. Audit Data Models and Semantics >> One or more Standards Track RFCs defining data models for representing audit >> information, including interaction records, agent identity, delegation >> context, authorization state over time, and action provenance. >> >> 3. Protocol Extensions or Profiles >> One or more Standards Track RFCs specifying extensions to existing IETF >> protocols (e.g., HTTP, OAuth, or token formats) to convey audit-related >> information. >> >> 4. Best Practices for Deployment and Operation >> An Informational or BCP document providing guidance for secure, >> interoperable, and privacy-aware auditing, including correlation across >> interaction types. >> >>> Begin forwarded message: >> >>> >>> From: "Mirja Kuehlewind (IETF)" <[email protected] >>> <mailto:[email protected]>> >>> Subject: New draft on AI Agent Auditing and proposed BoF/WG charter >>> Date: 19. May 2026 at 10:03:46 CEST >>> To: [email protected] <mailto:[email protected]> >>> Cc: Henk Birkholz <[email protected] >>> <mailto:[email protected]>> >>> >>> Hi all, >>> >>> We been working on auditing for AI agents and submitted yesterday a new >>> draft that proposes a high-level architecture. Auditing is becoming >>> increasingly important for monitoring long-running workflows, trust, and >>> also due to regulatory requirements. The proposed architecture takes a >>> holistic approach to enable monitoring for the whole agent chain. However, >>> please have a look directly at the draft here: >>> >>> https://www.ietf.org/archive/id/draft-kuehlewind-audit-architecture-00.html >>> >>> In parallel and given the BoF deadline is already this Friday, we started >>> working on a proposed charter. We believe the proposed work would be in >>> scope for the IETF and would likely need a new working group, therefore we >>> thought it might be useful to provide already a strawman charter to outline >>> the potential scope. Please see here: >>> >>> https://github.com/mirjak/draft-audit-architecture/blob/main/audit-charter.md >>> >>> We would be very interesting to get some quick feedback (before Friday), >>> especially about: >>> >>> 1) Is there general interest in agent auditing work in the IETF? Are there >>> other people who maybe already work on this topic or a planning to? >>> >>> 2) Any comments on the proposed scope of the work? Is the scope clear? Is >>> the IETF the right place for this work? Does this need a new working group? >>> >>> 2) Any comments on the proposed architecture or any additional work in the >>> space! >>> >>> Thanks! >>> Mirja & Henk >> >> -- >> WIMSE mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
