[Audit] Re: Records for declined actions [was: Re: Question on AUDIT charter's use case scope]

[Mikhail Sergeev <[e-mail]>]

Hi Mirja,

I've updated #53. It now only extends the existing sentence in Deliverable
1:

"This document might also identify needed protocol extensions and describe
what verification of audit information can establish, under what
assumptions, and with what limitations."

This makes the topic explicit while leaving its treatment to the working
group. Sections 4.2 and 8 of the architecture draft already discuss it.

The questions on what individual specifications should say are in
https://github.com/mirjak/draft-audit-architecture/issues/32
for further discussion. Nancy, your review question is item 1 there.


Mikhail

On Thu, Sep 17, 2026 04:08 PM, "Mirja Kuehlewind (IETF)" <
[e-mail]> wrote:

> Hi Mikhail,
>
> That makes it more clear to me. But do we need this level of details in
> the charter. These seems very specific requirement that the working should
> develop, discuss, and reach consensus on; and not something that we should
> write in stone in the charter without that detailed discussion. I’m not
> saying that these requirements are wrong but if we want or can address all
> of them is for the working group to decide when developing the data model
> and formats.
>
> Mirja
>
>
>
> On 17. Sep 2026, at 15:02, Mikhail Sergeev <[e-mail]>
> wrote:
>
> Mirja,
>
> You're right: a format alone can't tell you which claims hold in a given
> deployment, and #53 doesn't make that boundary clear.
>
> What I'm after is smaller. One system can log that a command was sent;
> another can read the same record as saying it was executed. A spec can
> settle that by saying what the record means and who asserts it. Whether
> anyone should believe the assertion is a deployment question.
>
> The same goes for checks a spec defines. RFC 9942 (5.2.1) defines the
> checks that show an entry is included in the log. RFC 9943 says what that
> relies on, trust in the receipt issuer (7.1), and that it doesn't show the
> statement is true (9.2). An AUDIT profile could say the same about its
> checks without assessing anyone's whole system.
>
> So I'd reword the sentence:
>
> OLD
> The working group's data model and protocol specifications, including
> profiles, will state which claims their audit information can support, the
> evidence and assumptions needed to assess those claims, and what that
> information does not establish.
>
> NEW
> The working group's data model and protocol specifications, including
> profiles, will state what their audit information means, who asserts it,
> any assumptions needed to interpret it, and what it does not establish on
> its own. Where they define or reference verification procedures, they will
> also state what verification can establish, what it does not establish, and
> the assumptions it rests on.
>
> Would that address your concern? If so, I'll update #53.
>
> Best,
> Mikhail
>
> On Thu, Sep 17, 2026 01:54 PM, "Mirja Kuehlewind (IETF)" <
> [e-mail]> wrote:
>
>> Hi all,
>>
>> Thanks for this proposal. I agree that this is critical point to be aware
>> of when you design and build a full auditing system. However, I’m not sure
>> what your addition on "which claims their audit information can support”
>> means for the work of a future IETF working group. We can specify data
>> models and formats such that an auditing system can use a standardized
>> format across domain boundaries. However, I don’t think a standardized
>> format alone can really give you a final answer about which claims can be
>> supported. That's what you need to ensure when budding a full auditing
>> system that is applying the building blocks that we can specify in this
>> group to enable interoperability.
>>
>> Or can you explain a bit more concrete what you mean by this?
>>
>> Mirja
>>
>>
>>
>>
>>
>> On 17. Sep 2026, at 12:10, Mikhail Sergeev <[e-mail]>
>> wrote:
>>
>> Hi Mirja, Nancy and all,
>>
>> The earlier sentence in #53 had a gap. It covered profiles only, and
>> Deliverable 2 can also specify new data models, which are not
>> profiles.
>>
>> The updated PR applies it to the working group's data model and
>> protocol specifications, including profiles. They are to state the
>> claims their audit information can support, the evidence and
>> assumptions needed to assess those claims, and what that information
>> does not establish.
>>
>> This revision builds on Nancy's proposal of 26 August and her message
>> of 14 September.
>>
>> https://github.com/mirjak/audit-bof-preparation/pull/53
>>
>> Nancy, thank you for the support.
>>
>> Best,
>> Mikhail
>>
>> On Thu, Sep 17, 2026 09:07 AM, Nancy Sahu <nancysahu=
>> [e-mail]> wrote:
>>
>>> Mirja,
>>>
>>> Answering your question directly, from my own deployment rather than
>>> from the thread.
>>>
>>> The new paragraph reads well and "invoked or declined actions" covers
>>> the case I care about.
>>>
>>> The general form is what I would still ask for: that each data model
>>> document state what its records do not establish, alongside what they do.
>>> My own records are signed and chained on the device, and the honest limit
>>> is that they establish what the device recorded, not that the action took
>>> effect at the far end — a reader who is not told that will assume
>>> otherwise. I would rather that kind of limit be a review question while the
>>> document is being written than something found after it is published.
>>>
>>> It is a statement about how the documents are written rather than a
>>> position on any specific case, so it commits the group to nothing it has
>>> not already decided. Deliverable 2 is where I would put it, which I think
>>> also answers the "where would we add that" in your reply to Parisa.
>>>
>>> Mikhail's PR #53 (
>>> https://github.com/mirjak/audit-bof-preparation/pull/53) has text that
>>> does this, and I support it.
>>>
>>> Nancy Sahu
>>> kriya native
>>> (I work on agent evidence records commercially and have an individual
>>> draft in this space.)
>>> _______________________________________________
>>> Audit mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> _______________________________________________
>> Audit mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>>
>