[Audit] Re: Next Wave of Updates for the Proposed Audit Charter - please review and comment

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

Hi Santosh, hi all!

Thanks for your input! Please see my comments below!

> On 19. Sep 2026, at 14:28, Santosh P K <[e-mail]> wrote:
> 
> Hi Henk, Mirja, all,
> 
> Thank you for the updated charter snapshot. Reading it alongside draft-kuehlewind-audit-architecture-01, I noticed a few operational topics that I couldn't find in the charter or in earlier list discussion. I'd like to ask whether the group thinks they belong in scope:
> 
> Volume and latency. One agent task may make hundreds of tool calls across domains. If each call produces a signed record, possibly sent to a collector, should the charter recognize the cost in added latency, record volume and storage?
I don’t think that latency is a problem as records are created after an event or at least off the critical path. But yes, there are of course things to consider on volume and storage. This might be something to add to the operational considerations we have in deliverable 4, but I guess that is mostly something to discuss in detail within the group later.

> Sampling vs. completeness. Large deployments will probably sample, batch or aggregate records. This seems to conflict with the recent "not observed vs. nothing happened" discussion, because a sampled-out record looks the same as a dropped one. Would it be useful for the architecture to state this trade-off explicitly?
Yes, that is also a good point to consider that the architecture is designed a way that sampling is possible and potentially be exposed. As you pointed out I think that is something for the architecture document to consider (rather than in the charter). Please free to open an issue in the arch GitHub for later discussion: https://github.com/mirjak/draft-audit-architecture/issues

> Collector unavailability. The draft describes both an external Audit Store and in-band storage via the peer agent (Section 3.2), but I couldn't find what should happen when either is unreachable. Should the agent stop (fail-closed), continue without recording (fail-open), or buffer? Should the architecture cover this?
I think this is again a good point for the operational considerations. However, I don’t see a reason why a record couldn’t be buffered but again probably something to future discuss in the group. And in addition I think it has to become very clear already with the discussion so far that an audit record might not be complete and an auditor would need to detect and understand that. 

> Retention and append-only logs. Section 9 leaves redaction and retention to the best-practice work item (WI-5), and notes that "the fact of registration leaks the existence of an interaction." Since entries in an append-only transparency log generally can't be removed afterwards, would it make sense to address this in the architecture (Deliverable 1) as well?
I think privacy considerations are a central point and we already aimed to make that stronger in the charter text. However, there should also be considerations in the architecture as well as the operational considerations document. I believe this is covered (even though not explicitly) in the charter.


> I'm not suggesting detailed requirements in the charter. If the group thinks these are in scope, one sentence in Scope might be enough, with the details in Deliverables 1 and 4. For example:
> 
> "Mechanisms are expected to be deployable at the volume and latency of agent tool-call traffic. The architecture will describe the trade-offs between record granularity, aggregation, and completeness, the behavior when audit components are unavailable, partial deployment along an interaction chain, and the interaction between retention requirements and append-only logs."

I would like to hear more input from other if these additional are helpful for setting the scope right (or too details)?

Thanks!
Mirja



> 
> Thanks
> Santosh P K
> Zscaler
> 
> On Sat, Sep 19, 2026 at 2:22 PM Ithelia Dias <[e-mail] <mailto:[e-mail]>> wrote:
>> Nicholas, all,
>> 
>> Your binding example is the one I have hit in practice, so a data point
>> rather than a position.
>> 
>> We run an authorization layer for machine-initiated payments. Each
>> decision comes back as an ES256-signed JWS naming the amount, the
>> recipient, the mandate it was checked against and the version of the
>> policy that produced it. Refusals are signed on the same path as
>> approvals.
>> 
>> The record has exactly the weakness you describe. It carries no audience
>> claim. Nothing inside it names the party it was issued for. Integrity is
>> intact and the association is unsupported, so a verdict legitimately
>> issued for one counterparty verifies perfectly when replayed at another.
>> We publish this as a stated limitation rather than leaving it to be
>> found, alongside a second instance of the same shape: the currency is
>> not under the signature, so a record for 340 does not distinguish 340
>> USD from 340 JPY.
>> 
>> What we do instead is weaker than a binding and worth naming as such.
>> The relying party is told to compare the recipient string in the record
>> against the transaction it is about to settle, exactly, and to treat a
>> mismatch as a refusal. That is an out-of-band agreement between the
>> integration and the operator, not evidence carried by the record.
>> 
>> Which is why I think your distinction is load-bearing rather than
>> editorial. In our case the two failures are genuinely different
>> conditions with different responses. A recipient that does not match is
>> a positively identified conflict: refuse and register it. The absence of
>> an audience claim is missing linkage evidence: the relying party cannot
>> detect misdirection at all, and no amount of checking the record will
>> tell it so. Collapsing both into "verification failed" would have lost
>> us the second case entirely, because there is nothing to fail on.
>> 
>> A record format that can say "this association is unsupported" as
>> distinct from "this association is contradicted" would let an
>> implementation report the first honestly instead of staying silent about
>> it. We had to put ours in prose on a documentation page.
>> 
>> Whether that belongs in the cross-domain interpretation work is for the
>> chairs, but from an implementation seat the distinction is not
>> theoretical.
>> 
>> I run Saifuro, which builds authorization tooling in this area, so I
>> have a commercial interest and this is review input rather than a
>> proposal to adopt anything of ours. Drafting was AI-assisted.
>> 
>> Ithelia Dias 
>> CEO & Founder, Saifuro 
>> saifuro.com <http://saifuro.com/>
>> 
>> 
>> 
>> From: Nicholas Templeman <[e-mail] <mailto:[e-mail]>>
>> To: <[e-mail] <mailto:[e-mail]>>
>> Date: Fri, 18 Sep 2026 16:42:55 +0200
>> Subject: [Audit] Re: Next Wave of Updates for the Proposed Audit Charter - please review and comment
>> 
>> Hi Mirja, Henk and all, 
>> 
>> Thank you for getting the revised AUDIT request into Datatracker. One additional 
>> example for the architecture/use-case discussion, beyond the missing-execution 
>> example I sent earlier: 
>> 
>> An action record passes its own integrity checks but belongs to a different 
>> originating request or delegation context. When presented as evidence for the 
>> requested action, integrity may remain valid while the association is 
>> unsupported. Missing linkage evidence and a positively identified binding 
>> conflict should remain distinguishable. 
>> 
>> Would that fit the proposed cross-domain interpretation work? It tests an audit 
>> relationship without prescribing a new identifier, record store or compliance 
>> policy. Our local request/output mismatch tests are relevant preparation, not an 
>> AUDIT interoperability result. My practical interest is in independent fixture 
>> and replay review as the record formats develop. 
>> 
>> One small maintenance point: the request's architecture link still selects 
>> draft-kuehlewind-audit-architecture-00; Datatracker shows -01, published 7 
>> September: 
>> https://datatracker.ietf.org/doc/draft-kuehlewind-audit-architecture/01/ 
>> 
>> I work on measurement and evidence tooling at CSOAI Ltd and have a commercial 
>> interest in this area. This is scoped review input, not a request to adopt our 
>> implementation. Drafting was AI-assisted. 
>> 
>> Best regards, 
>> Nicholas Templeman 
>> [e-mail] <mailto:[e-mail]> 
>> _______________________________________________ 
>> Audit mailing list -- [e-mail] <mailto:[e-mail]> 
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> 
>> 
>> _______________________________________________
>> Audit mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> _______________________________________________
> Audit mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]