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

[Henri Sirkkavaara <[e-mail]>]

Sumit, Nicholas, Mirja,

Sentence (2) named draft-sirkkavaara-vaara-receipt as one of the mechanisms that verify without reaching the issuer, with key resolution out of band. Sumit's objection applies to that draft as much as to the CSOAI rule Nicholas checked. Revision -07 never used the word revocation.

Section 10 is careful elsewhere about negative claims: an absent refusal is evidence only inside a declared coverage boundary, a missing receipt does not mean the action did not happen, and no ordering over classes may be inferred. Revocation was the one property it left unstated.

Revision -08 states it, as the second paragraph of Section 10:

Verifying that signature establishes that the key named under "alg" produced the signed payload and that the payload has not changed since. It says nothing about the state of that key now. Offline verification is a computation over the parameters the consumer holds, while revocation is a property of the present, and this document defines no revocation mechanism and places no freshness requirement on key material. A consumer MUST NOT treat a signature that verifies as evidence that the signing key is still valid. Where a decision depends on revocation state, the key resolution path and the staleness a deployment accepts are operational parameters of that deployment and MUST be stated by it; the receipt does not carry them.

The wording follows Sumit's framing, and it puts the freshness bound on the deployment the way a validated cache carries its refresh interval in RPKI.
Mirja, on scoping. Nicholas said CSOAI will add the sentence to its published verification rule, and this revision puts it in a draft. Each of us made the repair by treating sentence (1) as a review rule and reading our own text against it, with no charter language in force.

Henri Sirkkavaara
Vaara - Runtime execution layer for AI agents
Built to see over the noise.
vaara.ioHelsinki, Finland

On Tuesday, September 1st, 2026 at 08:39, Mirja Kuehlewind <ietf=[e-mail]> wrote:

> I think these requirements are too detailed for the charter. Further I would prefer if we narrow the framework down to an architecture overview document which explains the terminology and many some basic use cases and if useful some main requirements. The focus of the work should be on the protocol specifications. I think the architecture/framework is something we should only do if it helps to understand the protocol.
>
>> Am 01.09.2026 um 06:33 schrieb nicholas <[e-mail]>:
>
>> 
>> Sumit,
>>
>> Accepted in full, and it strengthens both halves. You are right that (2) creates an obligation under (1), and right about what the obligation is: revocation is a fact about the present, and offline verification is a computation over the past. Nothing a record carries can testify about now.
>>
>> The RPKI shape is the one to copy: validation deliberately offline at decision time, with freshness carried as a stated operational parameter rather than smuggled into what validation claims to establish. So under (1), for any offline-verifiable mechanism, the framework should require exactly your sentence - that offline verification establishes signature validity and key binding as of the verification parameters held, and does not establish revocation state, which is a property of the present and must be stated separately, with its freshness bound, where a mechanism provides it.
>>
>> One implementation report, because this thread keeps auditing its own participants: our published verification rule does not state the revocation limit either. A reader who fetched our verifier yesterday verifies with yesterday's trust anchor; if the key were revoked this morning, the verdict would not change and nothing in our text says so. That is the second unstated property this thread has caught in our estate - the first was a signed flag with no signature bytes behind it. We will add the revocation sentence to our published rule and note the correction.
>>
>> For the amendment itself I would leave (2) as posted and fold your sentence into (1)'s rationale, so the group still votes on the same two sentences already on the table.
>>
>> Warm regards,
>> Nicholas Templeman
>> CSOAI Ltd (Council of AI)
>>
>>> Replying to [e-mail], [e-mail] on August 31, 2026, 5:53 PM
>>>
>>> From: [e-mail]
>>> To: [e-mail]
>>> Cc: [e-mail], [e-mail], [e-mail]
>>> Date: August 31, 2026, 5:53 PM
>>> Subject: Re: [Agentproto] Proposed charter text: evidence requirements (was: Support for the AUDIT BoF at IETF 127)
>>> Nicholas,
>>>
>>> Sentence (2) requires verification without contacting any service, including for key resolution. Sentence (1) requires the framework to state what evidence does not establish. So (2) creates an obligation under (1), and the thing offline verification cannot establish is revocation.
>>>
>>> A party holding the records and the verification parameters can establish that a signature is valid and that the key is the one bound to the identity. It cannot establish that the key was still valid when the record was made, or is valid now, because revocation is a fact about the present and offline verification is a computation over the past.
>>>
>>> Routing hit this with RPKI. Validation is deliberately offline at decision time: a router checks a route against a locally held validated cache rather than reaching anywhere. That is what makes it affordable in the forwarding path. The cost is that the cache has a refresh interval, and the freshness of the cache is a stated operational parameter rather than something the validation establishes.
>>>
>>> So the honest form is that offline verification establishes signature validity and key binding as of the parameters held, and says nothing about revocation. That belongs under your sentence (1) rather than as a caveat on (2).
>>>
>>> Sumit P. Ahuja
>>> Main Labs
>>>
>>> On Sun, Aug 30, 2026 02:39 AM, nicholas <[e-mail]> wrote:
>>>
>>>> Nancy, Syed, all,
>>>>
>>>> Combined amendment as asked. Append these two sentences to the framework bullet that ends "...including the confirmation and evidence requirements for AI agent operations":
>>>>
>>>> (1) "For each evidence mechanism it specifies, the framework will state the properties the evidence establishes and the properties it does not establish, and a claim not so stated will not be assumed."
>>>>
>>>> (2) "Where the framework specifies evidence for agent operations, it will not assume the availability of an online service at verification time: verification will be specified such that a party in possession of the records and the associated verification parameters can complete it without contacting any service, including for key resolution."
>>>>
>>>> Neither names a format. They only constrain how results are stated and how verification is specified if an evidence line remains.
>>>>
>>>> Sentence (2) is already the verification procedure in draft-sahu-agent-action-receipts-00: records plus a trust anchor obtained out of band, no network, no service run by the producer. The same shape appears for SCITT Receipts (verifiable without online access to the Transparency Service once the relying party holds the Receipt and verification parameters) and in draft-sirkkavaara-vaara-receipt (recompute and verify without access to the issuer; key resolved out of band). Keep "including for key resolution" — that is the conformance edge.
>>>>
>>>> Sentence (1) is the review-time rule for the failures already reported on this list: a claim labelled stronger than the bytes support, and attestation that only reaches as far as something signed points. Adjacent composition work already separates what a Receipt or Attestation Result establishes from what it does not; the charter should require that separation to be written down.
>>>>
>>>> On scope: support Mirja's move of audit formats and collection out of scope, with Mikhail's Coordination entry to RATS, SCITT, and draft-kuehlewind-audit-architecture. These two sentences are not an audit mechanism. If the group drops the framework evidence line, both go with it, and that decision should also settle what "auditability" still means in Key Considerations.
>>>>
>>>> One accept-or-reject edit.
>>>>
>>>> Nicholas
>>>>
>>>> _______________________________________________
>>>> Agentproto mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> Agentproto mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]