Return-Path: X-Original-To: agent2agent@mail2.ietf.org Delivered-To: agent2agent@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A3240FC149AD for ; Fri, 5 Jun 2026 16:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780703203; bh=/J8kLNgqirO990oUEDfcLor14u56rS3ZMkplUlDMOWU=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=c37VA5nz35IMdO6XaM2oQVheM7gFxPeStqDv/q9bCEpcPC4Oi835NBtv/scQrWO0P 3R/KpBf7n5CtVsjswD7xdA5I1BvsktTg0PFHnhTwaMWieaiGzzUJoqYRekB4iEdEws 4gVHV/n7IETnekvMhcJC7VlJh6Gtn/M46VWaBaGY= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HxgqXQMrbem for ; Fri, 5 Jun 2026 16:46:42 -0700 (PDT) Received: from mail-dy1-x132d.google.com (mail-dy1-x132d.google.com [IPv6:2607:f8b0:4864:20::132d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5385BFC14854 for ; Fri, 5 Jun 2026 16:45:12 -0700 (PDT) Received: by mail-dy1-x132d.google.com with SMTP id 5a478bee46e88-3078e0dcd67so555749eec.0 for ; Fri, 05 Jun 2026 16:45:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780703111; cv=none; d=google.com; s=arc-20240605; b=c72VwYtpPZMN6XfzvokXtv1+VdUyG9YinxeNqgA9/kpdGy+HoS/GREFTjrLp9hcUiL t5iMIkq7djUsyIw50lAwhK2UpM7slbysaCSPRA01u+Xtn5/NZwwkbV9zBu1wHxUGcGUm yIQuAB6fPKI7s2AOkLSZnA3inwmeKTPBRWfgdRt7z/bETwJJo92amJ+MQsU7Es4stSIU C3pjn/9JJ56Z+sw1ynE62xMATMdY0trt18GQ55SxPwCorLyMyTcPEVl5gp0YLIt128D+ NuqXlM1Gz6axY99+4Wdzd7mXxTTs4G0wz8RZL0ZTMy8/j42RkRPbMT1VsJ5r8LgfiH5M PrCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=RK/rlmhy31Q4mGv++XjgmTwvPA2RtT8WzMT7tEqaVEs=; fh=MurkKiy8b25Q0C+pH2w/si4qeYl/I4RzVQuueL9j3eI=; b=D480irIgj76jJt1CUB42sGqKHKOzG7zrSVuR64QMz6KK1GfHIV8VhDMtSFnIaRfSMB QwHqQ80ycyTKR0uNyC45v8ccbX4d4SkGeOx2dkzq4xZkqwzg5f6gV/dCKa6LEzEnliqa wGkbLnng3v9L5ceeBflV3o3q7Ub+p5TgVVFapLs+fq4FwIQtuBUUUCM2zTBsmBW+cSx5 8K4ztPgYmyE8wnNA42B0vXQdbWONglFhIotHKJ9+qR+00+2y29aEbzSht5KN13WQdKVd dfJGi/c6BMtWVNYohWoe49i6g+QAX+bYTg8yJ/cTdbkKLlzn4EjzKPdtuFSjHcyjEzxQ c21g==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780703111; x=1781307911; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RK/rlmhy31Q4mGv++XjgmTwvPA2RtT8WzMT7tEqaVEs=; b=M52UFeStVxVoWzrC20zjjrVkVWVy6SjgwBABR1E0KlpKVV+jzM8LjkWcmFxJvuOSfK 78qmrQ+B4pPVdxpKQrnZpMyb0kphd7ZvBheSocLm+cVAVgMyJeooCbuqabuTCWeZZ2LL sDKJf6us+/omOrd7lJ8CTqZ2Y2HK8c37UzVIXzmEDlmfRHDYNRNRZmhsoc73w5H9pJ+T YomY76eQU61Jfg3/ylbl5ShLSDRF7GwP8kMrLnc3XMHyGfQwlCai2YA9BXYMGNTIVsxr Gxdte7ddQQNVBjCik8jhvtiX9llh9+ez8MVhCBFW85Ui8alTmF+TLRM8eOorMsPESqyf nayA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780703111; x=1781307911; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RK/rlmhy31Q4mGv++XjgmTwvPA2RtT8WzMT7tEqaVEs=; b=kPQL7eH2I8kVxIRuiarxMvwwnUGjS9tuzq7gR6oQAFp8wrHUPy8Sxg1M/gTxP4VfUV p/IHi0fvEjN8xijhAGv1/P5NyZJ3y4iVhv5ua0fPDFBZ30LArVLhJe/hid8EdXWloAFI 3vGMSsgTLcLm/vPCALoHrXeaR53lPWTN2vexqeIl39u+qUeXHXZpNFZQrjYUk/p/LyZb TlRkKmUJ2P9vE4T/KtriY4JdzN5VNitLJPBx2mCdy1nVta+xpgSoiP3VYijeLxbzCq4R gvembURouugSeYRwpY7glzQLvvrJnzEJckjO3BrQTF7F2d54Lh8n+Fm8y2sJxNPLxHnW GDzg== X-Forwarded-Encrypted: i=1; AFNElJ+B7SFfQ2BQYcNczeAYh7QdFyBPCyDpFwT+7Vhm8bqhtik7D/BmcMRp1QTrEjwM66PclM96dUS1Sz8TFA==@ietf.org X-Gm-Message-State: AOJu0YxdJDQrJHGas04C4bNz7lY2EwsGNwbII0ARpXY9qM334bpi85Dn Y0MvSPU8gge60foWaB4hzUlMU9JRspnIMevpzBLFPsLs2HPD/iSQZgBKpowba3oBjHLFDdAQ2fi OCpspJ+/tOPvFQs+5kDN5807uqouvSA== X-Gm-Gg: Acq92OEO99ysJao7m6BPJ7BjWwCV5yn62kaiL+1qBpxGYgic30HpUFI1Y+vUsFVO2BG rquU6hwuprgXpM1UTrpGw1uAYtxX/haeazthRhNb9zM5hpA6J1SjpblTWnFwHqN0eka/91jpcDK Nls8zyfwD7eeOBCI5oY98WqzgwpyTigM/U5CiJNLeEzmv7/o0q5TEM9GP31BqknIXQeHSGtVclc L5P/5ogtfUAH5vN6Zk2JzfeZg0r1cXqE+rPUEa29kMYFaE0N0LP68tqer+NWZH5V/LghnIRnsyp e6JlhiP8suKtBH9bYKa6PEmETFUV4GBh5PfY1CY5DLyXCYWa3iqaAIY4z7lZHl7e5qX6PjKmsVE siWhahp0OB0KVDvY+xV2w/uq0tv6oNsT5Wbk1 X-Received: by 2002:a05:7300:2209:b0:304:c651:bdea with SMTP id 5a478bee46e88-3077b22a913mr3456889eec.21.1780703111214; Fri, 05 Jun 2026 16:45:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Deb Cooley Date: Fri, 5 Jun 2026 19:45:00 -0400 X-Gm-Features: AVVi8Ccq5XDINOLboo3u0yKWYejtkuVsnkNdR6WZbPprXcuDIVlIx5Wx6HJKvHI Message-ID: To: Mirja Kuehlewind Content-Type: multipart/alternative; boundary="00000000000064faa106538a406e" Message-ID-Hash: FKJP3VIE2KAVZ6U7JY664VX62SOIKPKF X-Message-ID-Hash: FKJP3VIE2KAVZ6U7JY664VX62SOIKPKF X-MailFrom: debcooley1@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: stndrds-inacio@andrew.cmu.edu, Henk Birkholz , Pamela Dingle , agent2agent@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bagent2agent=5D_Re=3A_bofreq-kuhlewind-agent-use-of-delegation-a?= =?utf-8?q?nd-interaction-traceability-audit_response?= List-Id: Standardization of AI Agent Communications Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000064faa106538a406e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just a quick note: Defer is the word I've heard used for 2+ years when a BOF is not taken up for the current meeting cycle. I guess we could have said your request was declined, but defer is the word I've seen used. Deb On Fri, Jun 5, 2026 at 4:57=E2=80=AFPM Mirja Kuehlewind wrote: > Hi Deb, hi Chris, > > Can you clarify what you actually mean by =E2=80=9Cdeferred=E2=80=9D? Fro= m my > understanding (and the datatraker states) you can either accept or declin= e > a BoF request. If the BoF request is declined for his meeting, the > proponent can decide so submit, or not, a new request for the next meetin= g. > Or does =E2=80=9Cdefer=E2=80=9D imply something else from your side? > > Also my understanding of the two stage BoF deadline was that one could > work on questions like your below in the two weeks in between for BoFs th= at > are a promising but may not be quite clear yet (maybe this what you mean > with =E2=80=9Cdeferred=E2=80=9D?). Before we had the two deadlines, espec= ially for > proposals that came in shortly before the deadline, there was no change t= o > coordinate with the proponents and therefore one could only do a yes/no > decision. Therefore the second deadline was introduced to have time to > reach out and clarify things. However, this seems a bit late now give the > second deadline is today and we received your input only recently. And it > also seems you already made a decision without further exchange with us. = If > this understanding of the two BoF deadlines is not the intended process, = we > would like to request the IESG to clarify the process and intention of th= e > two deadlines (maybe in an IESG statement)! > > See below for answers to your questions. > > > On 3. Jun 2026, at 11:51, Deb Cooley wrote: > > > Mirja, Henk, and Pam, > > The Agent Use of Delegation and Interaction Traceability (AUDIT) BOF > request is being deferred. > > While the concept of auditing the actions of an agentic agent is a good > concept, the current proposal is too broad. The intent/policy concepts > work better in a legal framework - not at the IETF. > > > The issues that need work: > > > 1. Objective: What question would be answered? (Is the AI model > operating correctly? Is its training data of proper provenance? Are the > actions correct?). Polish what is =E2=80=98in scope=E2=80=99 and what is= =E2=80=98out of scope=E2=80=99. > Be precise and concise. > > > > You asked the question of what=E2=80=99s the gaol of auditing. However, t= hat=E2=80=99s not > the problem we try to solve. The objective of auditing are the same as > today (effectively it needs to be flexible enough to address all of these > cases). The problem we motivate in the BoF request and proposed charter i= s > that today auditing systems are not able to capture all actions and > relevant events for complex multiple domain (semi-)autonomous systems. Th= e > intention is to design a flexible system that further is able to evolve > over time (by adding new record types on a need bases for different use > cases and trust requirements) as these system are quickly evolving. > > We also further clarified this in the proposed charter based on comunity > feedback by adding the following sentence: > > "The group will work on the minimal set of audit information and consider > a registry to enable experimentation and fast deployment for additional > data models.=E2=80=9D > > See here: https://github.com/mirjak/audit-bof-preparation/pull/21/changes > > > 2. Privacy: There are undoubtedly privacy issues in the audit space > where the control of privacy in the face of 'reasoning traces' will be ve= ry > difficult. This is especially problematic when the concept of transparen= cy > logs is added. It is better to build privacy in vice bolting it on later= . > > > Yes, we absolutely agree that privacy is important and we need to conside= r > it from the beginning. This was always the intention and we also had > multiple people making the point that privacy is important and one of the > core poinst for the working group. For me that is also one strong reason = to > have this work in the IETF because I think the expertise here is high! > However, we wouldn't be able to address this entirely before chartering b= ut > based on the community feedback we added this to the charter explicitly, > see here: > > https://github.com/mirjak/audit-bof-preparation/pull/12/changes > > Can you further specify the privacy issues you mention specifically for > transparency logs? > > > 3. Audit protocols: There are many places that audit protocols are > being worked on - OCSF, CADF, OpenTelemetry. It isn't clear whether this > 'protocol' is targeting a new protocol or profiling existing work from > other forums. > > > If you look at the architecture document as well as the charter, we don= =E2=80=99t > really aim for much of new protocols here. It=E2=80=99s about data models= and > extensions/profiles to existing (IETF) protocols (but OCSF could be used = as > well). We are also looking into OpenTelemetry and believe that the propos= ed > audit architecture could be adopted there, as the identified challenges > with existing logging apply. But that is an on-going effort. Specially > OpenTelemtry came up multiple times in the discussion already and we > respectively added the following sentence to the charter to explicitly > address this: > > "The working group may also define protocol-independent data > representations intended for use by non-IETF logging, telemetry, or audit > systems, while avoiding standardization of those external systems > themselves.=E2=80=9D > > See here: https://github.com/mirjak/audit-bof-preparation/pull/21/changes > > > 4. Interoperability: The core of the IETF mission. Please state the > interoperability requirements, advantages and rationale (especially in th= e > face of privacy concerns). > > > The charter says the following: > > "Cross-domain interactions lack interoperable means to exchange or verify > audit-relevant information about the participating agents and their > interactions=E2=80=9D > > I=E2=80=99m not fully sure what you mean by interoperability requirements= though? > Isn't interoperability a requirement in itself for a proposal? > > > 5. Community: Where is the community related to this effort and are > there implementers? > > > On the agent2agent mailing we already got a lot of positive feedback from > people who are interested in this work, have a problem to solve, and woul= d > like to implement it. So it seems quite clear that there is a relevant > community in the IETF. Further, we are currently (in preparation of a Bof= ) > reaching actively out to more people who may have very concrete use cases > and might be interested to implement. However, this is for me the main > question to answer to have a BoF where we see who shows up and speaks up. > > > > 6. Contrived linkages: > > scitt: It is unclear to us why scitt - a software supply chain protocol - > is useful here. There are multiple examples of transparency systems - > Certificate transparency, key transparency, and the SCITT transparency. > Why is scitt the right choice? And what value does yet another > transparency system offer here. > > Certificate and key transparent do not apply as they are very specificall= y > only addressing certs and keys. However, SCITT is a bit more generic as > that it logs =E2=80=9Csigned statements=E2=80=9D for "compliance=E2=80=9D= . We thought this is > actually a reasonable match and therefore we could re-use that work and > maybe specify a profile. We also send our BoF proposal of that reason to > the scitt list and got at least one positive reply. However, we hope to > have more discuss there. > > Further, your question, listing those three examples for transparency log= s > in one go, already indicated that we should maybe not reinvent the wheel > every time we need a transparency log. So again, we are really hoping to > reuse as much as we can of existing work. This overlap with existing work > in the IETF is for us a strong reason to have the work in the IETF. But I > guess that is another BoF question to answer during the BoF. > > > > rats: We can think of no reason why rats is mentioned. The attestation o= f > software doesn=E2=80=99t really seem to be in scope for rats. > > RATS Attesters demonstrate that the audit-logs themselves are compliant > (instead of a "trust us" self-assertion) and any environment running an > autonomous system (AI agent) can take on an Attester role, include the > record generating code into its TCB and demonstrate that the records are > created in a believable manner. This is a starter scenario to keep the > scope tight, but other scenarios are of course possible. The agent itself > can be part of the TCB and thereby provide Evidence about tool calls, > authentication events, and trustworthy workload identity provisioning > directly where it happens. If confidential compute is involved, > geo-location, spawning of sub-agents, and capabilities, such as key or > platform attestation can be demonstrated via Evidence in a scalable manne= r. > All these facets complement a robust audit framework where the results > become part of the audit-log made transparent via a SCITT Transparency > Service (e.g. Microsoft Signing Transparency). > > > vcon: We are unfamiliar with this work, why is it being mentioned? > > VCon works on conversation records (see here: > https://datatracker.ietf.org/wg/vcon/about/). At the last joint > dispatch/secdispatch meeting Henk presented Verifiable Agent Conversation > Records - VACR ( > https://www.ietf.org/archive/id/draft-birkholz-verifiable-agent-conversat= ions-00.html). > The VCon authors highlighted that it would be a perfect fit for their VCo= n > Core desgin and Henk is currently working with them to create and align > VCon CDDL to enable the use of VACR as a VCon extension. VACR is a > candidate for the conversation record (representing an agent trajectory), > as mentioned in the BoF request. > > > > Way forward: > > Spend some time tailoring this BOF request into a more polished request - > scope it down to an achievable idea. We do recommend that the proponents > spend a fair amount of time understanding the work that both oauth and > wimse working groups do. Those working groups should be consulted on a > regular basis. Consider whether a profile of OpenTelemetry created within > the OAUTH and/or WIMSE working groups might not fill the need. If it > won't, be prepared to explain the gaps. A clear, distinct problem(s) > statement will likely lead to a much stronger proposal. > > Can you clarify a bit more what is not clear in the problem statement? > Your points below didn=E2=80=99t really address the problem statement its= elf, > except maybe point 1 but I hope I could clarify the misunderstanding of > scope a bit more now. > > As you can see, we already continued to work on the charter based on the > community feedback that we got so far on the agent2agent list. We also > looked into oauth and wisme, however, we don=E2=80=99t think this kind of= work > would be in scope for these groups and are now really surprised by this > proposal. Oauth is just recharting and does a lot of good work that we > would like to related to in order to audit authorization and delegation > decision correctly, however, that is only a small part of the needed > auditing. Creating a OpenTelemetry profile in outh or wimse seems an > extremely wide stretch for their charters. > > However, if that is what the community input would indicate during the Bo= F > that is also a possible outcome. This would not be the first BoF where th= e > outcome is not a new groups but work in existing groups. However, we > believe this work is definitely broader than this and we believe a BoF > would be very value to explicitly answer the question about community > interest and relation to the IETF (or other works) before a group is > chartered. That's also what the community feedback indicated to us so far > and why we decided to put in a BoF request (rather than going to dispatch= ). > > Mirja & Henk & Pam > > > > > Gather the community that is interested in implementing the protocol or > idea you are proposing. > > > If the proponents would like a mailing list for this work, we would be > happy to help with that. > > > Deb and Chris > > Sec ADs > > > --00000000000064faa106538a406e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just a quick note:=C2=A0 Defer is the word I've h= eard used for 2+ years when a BOF is not taken up for the current meeting c= ycle.=C2=A0 I guess we could have said your request was declined, but defer= is the word I've seen used.=C2=A0=C2=A0

Deb


On Fri, Jun 5, 2026 at 4:57=E2=80= =AFPM Mirja Kuehlewind <ietf@kueh= lewind.net> wrote:
Hi Deb, hi Chris,

Can yo= u clarify what you actually mean by =E2=80=9Cdeferred=E2=80=9D? From my und= erstanding (and the datatraker states) you can either accept or decline a B= oF request. If the BoF request is declined for his meeting, the proponent c= an decide so submit, or not, a new request for the next meeting. Or does = =E2=80=9Cdefer=E2=80=9D imply something else from your side?

=
Also my understanding of the two stage BoF deadline was that one= could work on questions like your below in the two weeks in between for Bo= Fs that are a promising but may not be quite clear yet (maybe this what you= mean with =E2=80=9Cdeferred=E2=80=9D?). Before we had the two deadlines, e= specially for proposals that came in shortly before the deadline, there was= no change to coordinate with the proponents and therefore one could only d= o a yes/no decision. Therefore the second deadline was introduced to have t= ime to reach out and clarify things. However, this seems a bit late now giv= e the second deadline is today and we received your input only recently. An= d it also seems you already made a decision without further exchange with u= s. If this understanding of the two BoF deadlines is not the intended proce= ss, we would like to request the IESG to clarify the process and intention = of the two deadlines (maybe in an IESG statement)!

See below for answers to your questions.

On 3. Jun 2026, at 11:51, Deb Cooley <debcooley1@gmail.co= m> wrote:

Mirja, Henk, and Pam,=C2=A0

The=C2=A0=C2=A0Agent Use of Delegation and Interaction Traceability= (AUDIT) BOF request is being deferred. =C2=A0
While the concept of auditing the actions of an agentic agent is a good concept, the current proposal is too broad.=C2=A0 The intent/policy concept= s work better in a legal framework - not at the IETF. =C2=A0


The issues that need work: =C2=A0

=C2=A0

1.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Objective: What question would be answered? =C2=A0(Is the AI model operating correctly? Is its training data of proper provenance?=C2=A0 Are the actions correct?).=C2=A0 Polish what is =E2=80=98in scope=E2=80=99 and what is =E2=80=98out o= f scope=E2=80=99.=C2=A0 Be precise and concise.

=C2=A0

You asked the question of what=E2=80=99s th= e gaol of auditing. However, that=E2=80=99s not the problem we try to solve= . The objective of auditing are the same as today (effectively it needs to = be flexible enough to address all of these cases). The problem we motivate = in the BoF request and proposed charter is that today auditing systems are = not able to capture all actions and relevant events for complex multiple do= main (semi-)autonomous systems. The intention is to design a flexible syste= m that further is able to evolve over time (by adding new record types on a= need bases for different use cases and trust requirements) as these system= are quickly evolving.

We also further clarified t= his in the proposed charter based on comunity feedback by adding the follow= ing sentence:

"The group will work on the min= imal set of audit information and consider a registry to enable experimenta= tion and fast deployment for additional data models.=E2=80=9D


<= span>2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Privacy: There are undoubtedly privacy issues in the audit space where the control of privacy in the face of 'reasoning = traces' will be very difficult.=C2=A0 This is especially problematic when the conce= pt of transparency logs is added.=C2=A0 It is better to build privacy in vice bolting it on later.

Yes, we absolutely agree that privacy is important and we need to consid= er it from the beginning. This was always the intention and we also had mul= tiple people making the point that privacy is important and one of the core= poinst for the working group. For me that is also one strong reason to hav= e this work in the IETF because I think the expertise here is high! However= , we wouldn't be able to address this entirely before chartering but ba= sed on the community feedback we added this to the charter explicitly, see = here:


Can you= further specify the privacy issues you mention specifically for transparen= cy logs?=C2=A0

=C2=A0

3.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Audit protocols: =C2=A0There are many places that audit protocols are being worked on - OCSF, CADF, OpenTelemetry.=C2=A0= It isn't clear whether this 'protocol' is targeting a new protocol= or profiling existing work from other forums.
=
If you look at the architecture document as well as the char= ter, we don=E2=80=99t really aim for much of new protocols here. It=E2=80= =99s about data models and extensions/profiles to existing (IETF) protocols= (but OCSF could be used as well). We are also looking into OpenTelemetry a= nd believe that the proposed audit architecture could be adopted there, as = the identified challenges with existing logging apply. But that is an on-go= ing effort. Specially OpenTelemtry came up multiple times in the discussion= already and we respectively added the following sentence to the charter to= explicitly address this:

"The working group = may also define protocol-independent data representations intended for use = by non-IETF logging, telemetry, or audit systems, while avoiding standardiz= ation of those external systems themselves.=E2=80=9D

See here:=C2=A0https://github.com/mirjak/audit-bof-pr= eparation/pull/21/changes=C2=A0

=

=C2=A0

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Interoperability: The core of the IETF mission.=C2=A0 Please state the interoperability requirements, advantages a= nd rationale (especially in the face of privacy concerns).
<= /div>

The charter says the following:
=

"Cross-domain = interactions lack interoperable means to exchange or verify audit-relevant = information about the participating agents and their interactions=E2=80=9D

I=E2=80= =99m not fully sure what you mean by interoperability requirements though? = Isn't interoperability a requirement in itself for a proposal?

=C2=A0

<= span>5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Community: Where is the community related to this effort and are there implementers?=C2=A0

On the agent2agent mailing we already got a lot of positive feedback from = people who are interested in this work, have a problem to solve, and would = like to implement it. So it seems quite clear that there is a relevant comm= unity in the IETF. Further, we are currently (in preparation of a Bof) reac= hing actively out to more people who may have very concrete use cases and m= ight be interested to implement. However, this is for me the main question = to answer to have a BoF where we see who shows up and speaks up.

<= blockquote type=3D"cite">

=C2=A0

= 6.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Contrived linkages: =C2=A0
scitt: It is unclear to us why scitt - a software supply chain protocol - i= s useful here.=C2=A0 There are multiple examples of transparency systems - Certificate transparency, key transparency, and the SCITT transparency.=C2= =A0 Why is scitt the right choice?=C2=A0 And what value does yet another transparency system offer here.

Certificate and key transparent do not apply as they are very specifically= only addressing certs and keys. However, SCITT is a bit more generic as th= at it logs =E2=80=9Csigned statements=E2=80=9D for "compliance=E2=80= =9D. We thought this is actually a reasonable match and therefore we could = re-use that work and maybe specify a profile. We also send our BoF proposal= of that reason to the scitt list and got at least one positive reply. Howe= ver, we hope to have more discuss there.

Further, = your question, listing those three examples for transparency logs in one go= , already indicated that we should maybe not reinvent the wheel every time = we need a transparency log. So again, we are really hoping to reuse as much= as we can of existing work. This overlap with existing work in the IETF is= for us a strong reason to have the work in the IETF. But I guess that is a= nother BoF question to answer during the BoF.



rats: We can think of no reason why rats is mentioned.=C2=A0 The attestatio= n of software doesn=E2=80=99t really seem to be in scope for rats.=C2=A0=C2=A0

RATS Attesters demonstrate that the = audit-logs themselves are compliant (instead of a "trust us" self= -assertion) and any environment running an autonomous system (AI agent) can= take on an Attester role, include the record generating code into its TCB = and demonstrate that the records are created in a believable manner. This i= s a starter scenario to keep the scope tight, but other scenarios are of co= urse possible. The agent itself can be part of the TCB and thereby provide = Evidence about tool calls, authentication events, and trustworthy workload = identity provisioning directly where it happens. If confidential compute is= involved, geo-location, spawning of sub-agents, and capabilities, such as = key or platform attestation can be demonstrated via Evidence in a scalable = manner. All these facets complement a robust audit framework where the resu= lts become part of the audit-log made transparent via a SCITT Transparency = Service (e.g. Microsoft Signing Transparency).


vcon: We are unfamiliar with this work, why is it being mentioned?

VCon works on conversation record= s (see here:=C2=A0https://datatracker.ietf.org/wg/vcon/about/). At the l= ast joint dispatch/secdispatch meeting Henk presented Verifiable Agent Conv= ersation Records - VACR (https://w= ww.ietf.org/archive/id/draft-birkholz-verifiable-agent-conversations-00.htm= l). The VCon authors highlighted that it would be a perfect fit for the= ir VCon Core desgin and Henk is currently working with them to create and a= lign VCon CDDL to enable the use of VACR as a VCon extension. VACR is a can= didate for the conversation record (representing an agent trajectory), as m= entioned in the BoF request.



=

Way forward: =C2=A0

Spend some time tailoring this BOF request into a more polished request - s= cope it down to an achievable idea.=C2=A0We do recommend that the proponents spe= nd a fair amount of time understanding the work that both oauth and wimse workin= g groups do.=C2=A0 Those working groups should be consulted on a regular basi= s. Consider whether a profile of OpenTelemetry created within the OAUTH and/or WIMSE working groups might not fill the need.=C2=A0 If it won't, be pre= pared to explain the gaps.=C2=A0 A clear, distinct problem(s) statement will likely = lead to a much stronger proposal.=C2=A0=C2=A0

Can you clarify a bit more what is not clear in the problem state= ment? Your points below didn=E2=80=99t really address the problem statement= itself, except maybe point 1 but I hope I could clarify the misunderstandi= ng of scope a bit more now.

As you can see, we already contin= ued to work on the charter based on the community feedback that we got so f= ar on the agent2agent list. We also looked into oauth and wisme, however, w= e don=E2=80=99t think this kind of work would be in scope for these groups = and are now really surprised by this proposal. Oauth is just recharting and= does a lot of good work that we would like to related to in order to audit= authorization and delegation decision correctly, however, that is only a s= mall part of the needed auditing. Creating a OpenTelemetry profile in outh = or wimse seems an extremely wide stretch for their charters.

=
However, if that is what the community input would indicate duri= ng the BoF that is also a possible outcome. This would not be the first BoF= where the outcome is not a new groups but work in existing groups. However= , we believe this work is definitely broader than this and we believe a BoF= would be very value to explicitly answer the question about community inte= rest and relation to the IETF (or other works) before a group is chartered.= That's also what the community feedback indicated to us so far and why= we decided to put in a BoF request (rather than going to dispatch).
<= div>
Mirja & Henk & Pam


=


Gather the community that is interested in implementing the protocol or ide= a you are proposing.


If the proponents would like a mailing list for this work, we would be happ= y to help with that.=C2=A0

=C2=A0

Deb and Chris

Sec A= Ds


--00000000000064faa106538a406e--