[Agentproto] Comments on framework and auditabilty [was: Re: [Agentproto] Proposed charter text: evidence requirements (was: Support for the AUDIT BoF at IETF 127)]

["Mirja Kuehlewind (IETF)" <[e-mail]>]

I think we should cut down the framework work to mainly provide a reference architecture that would help understand how the protocols, we want to standardize in this group, will be applied. Therefore I would like to see the list on the framework part in charter cut down. Especially the point mentioned below on “authentication and authorization” is in the mean time already covered ye the recharter of the oauth group; so I think we can cut that point…?

On the part of the charter that mentions auditability. This text only says that an identifier that will be developed in this group could/should also be used for auditing. That is true. However my understanding would be that auditing mechanisms itself are out of scope; this group would only standardize the protocols pieces that are needed for (live) session/lifecycle management. I think this focus is right. I guess we then could also add record formats and mechanism to maintain and collect auditing information as out of scope, should we?


> On 26. Aug 2026, at 22:10, Leslie Daigle (ThinkingCat) <ldaigle=[e-mail]> wrote:
> 
> Got it — thanks for the reframing.
> 
> Leslie.
> 
> On 26 Aug 2026, at 11:17, Nancy Sahu wrote:
> 
> Understood - thank you for the pointer, and here is the same input in the form you asked for. Both suggestions below attach to sentences already present in charter.md; neither asks the working group to take on new scope.
> 
> In the AI Agent Protocol Framework deliverable, the bullet currently reads: "Describe agent-specific integration for agent authentication and authorization about how existing and emerging mechanisms are composed and applied in AI agent scenarios, including the confirmation and evidence requirements for AI agent operations."
> I suggest appending one sentence: "Where the framework specifies evidence for agent operations, it will state the properties that such evidence establishes and the properties it does not establish, and will not assume the availability of an online service at verification time."
> 
> Rationale: "evidence requirements" is already a framework deliverable, but as written the term is open enough that two implementations could satisfy it and still disagree about what a given record means - which is an interoperability failure, not a security one. The two constraints proposed are the ones that decided interoperability in deployment. First, verification without an online service: evidence produced in regulated or disconnected environments has to be checkable by a party who has the records and nothing else, so if the framework assumes a reachable service at verification time those deployments cannot conform. Second, stating the negative: a record cannot establish that an action which was never recorded did not happen, and a record sequence cannot by itself reveal that entries were removed from its head. If the framework does not say so, the natural reading of "evidence" is stronger than anything an implementation can deliver, and implementers will diverge on which guarantee they think they owe.
> 
> The first Key Considerations bullet already ends "...and auditability of agent-initiated actions distinct from user-initiated actions", but no deliverable currently carries that property other than the evidence clause in (1).
> I suggest the working group treat those two as a pair: if the evidence clause in the framework deliverable is retained, the consideration is discharged and needs no change; if the evidence clause is narrowed out of the framework, then "auditability" should come out of the Key Considerations at the same time, so the charter does not name a property that no deliverable addresses. I raise this because at least one amendment currently under discussion would move security-adjacent work out of scope, and the evidence clause could be removed as a side effect rather than as a decision.
> 
> I am happy to write text for either.
> 
> Nancy Sahu
> kriya native
> 
> Agentproto mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> --
> 
> Leslie Daigle
> Principal, ThinkingCat Enterprises
> [e-mail] <mailto:[e-mail]>_______________________________________________
> Agentproto mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]