[agent2agent] Re: bofreq-kuhlewind-agent-use-of-delegation-and-interaction-traceability-audit response

[Deb Cooley <[e-mail]>]

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 PM Mirja Kuehlewind <[e-mail]> wrote:

> Hi Deb, hi Chris,
>
> Can you clarify what you actually mean by “deferred”? From my
> understanding (and the datatraker states) you can either accept or decline
> 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 meeting.
> Or does “defer” 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 that
> are a promising but may not be quite clear yet (maybe this what you mean
> with “deferred”?). Before we had the two deadlines, especially for
> proposals that came in shortly before the deadline, there was no change to
> 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 the
> two deadlines (maybe in an IESG statement)!
>
> See below for answers to your questions.
>
>
> On 3. Jun 2026, at 11:51, Deb Cooley <[e-mail]> 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 ‘in scope’ and what is ‘out of scope’.
> Be precise and concise.
>
>
>
> You asked the question of what’s the gaol of auditing. However, that’s 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 domain (semi-)autonomous systems. The
> 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.”
>
> 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 very
> difficult.  This is especially problematic when the concept of transparency
> 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 consider
> 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 but
> 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’t
> really aim for much of new protocols here. It’s 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 proposed
> 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.”
>
> 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 the
> 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”
>
> I’m 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 would
> 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 specifically
> only addressing certs and keys. However, SCITT is a bit more generic as
> that it logs “signed statements” for "compliance”. 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 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 another BoF question to answer during the BoF.
>
>
>
> rats: We can think of no reason why rats is mentioned.  The attestation of
> software doesn’t 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 manner.
> 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-conversations-00.html)
> The VCon authors highlighted that it would be a perfect fit for their VCon
> 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’t really address the problem statement itself,
> 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’t 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 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
> 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
>
>
>