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

[nicholas <[e-mail]>]

Nancy, Sumit,




Two replies in one, since your points met in our estate this week. I would rather report what happened than argue a position.




Nancy - I support both halves of your sentence, and can offer a running implementation rather than an opinion.




On verification without an online service: our verifier is a zero-dependency script a reader downloads once, and it opens no sockets. I ran it this evening from an empty directory with nothing but curl and node, then killed the origin and re-ran it. Same result. That property is worth specifying because it is easy to lose by accident - a verifier that quietly resolves a key over the network at check time looks identical to one that does not, until a disconnected deployment tries to conform.




On stating what evidence does not establish: this is the half I would push hardest for, because we got it wrong instructively. Our published index carried "signed": true on 150 rows that had no signature bytes. Accurate in intent, useless as evidence - nobody could tell signed from asserted by looking. The repair was not to relabel the flag but to publish the signature, public key and preimage rule for every row. Your sentence would have caught that at review, which argues for it better than I could from first principles.




Sumit - your selection point applies to us, and this is an attempt at it rather than a solution.




Our published set is a prefix of a longer hash chain, so a card we withhold is not distinguishable from one that never existed. This evening I published the full chain skeleton: every position in order with id, parent and signature, and the withheld bodies as counted tombstones rather than absences.




Then I checked what it buys. A withheld position is only cryptographically attested if some published card's signed body names it as parent. Exactly one of our twenty-two is. The other twenty-one are consecutive, so nothing signed points at them and they exist only because an unsigned manifest says so. So: silent removal adjacent to a published card is now detectable; silent removal inside a withheld run is not. Signing the manifest is the next step and would make the set non-repudiable, which still would not prove we did not choose it.




On your independence gap I have only agreement. If the anchoring service sits inside the domain whose conduct is examined, the construction gives ordering and not independence. That is better stated as a protocol property than as a business claim.




Nancy - happy to write the offline-verification half up as candidate text with ours as one reference point, on the understanding that one implementation is an existence proof and not a consensus.




Warm regards,

Nicholas Templeman

CSOAI Ltd (Council of AI)

Replying to nancysahu=[e-mail], [e-mail] on August 26, 2026, 4:17 PM


From: nancysahu=[e-mail]

To: [e-mail]

Cc: [e-mail]

Date: August 26, 2026, 4:17 PM

Subject: [Agentproto] Proposed charter text: evidence requirements (was: Support for the AUDIT BoF at IETF 127)


      
      
   
   

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.





1. 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.





2. 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]


To unsubscribe send an email to [e-mail]