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

[Lars Kersten Kroehl <[e-mail]>]

Hi Mirja —

thank you for the comment. The group should settle this, agreed. I'm not arguing that verifiable has to mean recomputable.

The thing I'd watch when you write up attestation: it isn't the same check as recomputation. Attestation tells you a record is authentic — it came from where it says it did. It doesn't tell you the verdict inside is right. Recomputation does that: someone re-runs the inputs and gets the same result, without trusting who issued it. Usually you want both.

The architecture already points here. Section 8 says no single Verifier or Transparency Service is enough, and 4.3 treats the Agent as untrusted. Recomputation is the one check that needs no trusted verifier at all, so it should sit next to attestation.

So yes, spelling out attestation would help — as long as verifiable still covers a recomputable record, and Deliverable 3 doesn't quietly make attestation the definition of it

Lars 
MolTrust




> Am 22.09.2026 um 15:26 schrieb Mirja Kuehlewind (IETF) <ietf=[e-mail]>:
> 
> Hi Henri, hi Lars, hi all,
> 
> The important part is that the charter captures the requirement that records need to be verifiable, which we added explicitly recently. How that is done, is for the working group to figure out.
> 
> However, verification doesn’t automatically mean independent re-computation. The architecture refers to an attestation service for verification and the charter notes respectively “attention workflows” in deliverable 3. Again the details are to be worked out by the group but I guess we could say more about the role of attestation in the charter if that would help clarity. Would that help?
> 
> Mirja
> 
>  
> 
>> On 22. Sep 2026, at 15:02, Henri Sirkkavaara <[e-mail]> wrote:
>> 
>> Lars,
>> 
>> I agree that a record of what a user permitted has to be recomputable by someone who does not trust the issuer.
>> 
>> For draft-sirkkavaara-vaara-receipt the corpus carries that. Seven independent parties have reimplemented the checker from the public spec and reproduced the verdicts, with no shared code. A charter can ask for that form of evidence.
>> 
>> There is a limit both our documents carry. AAE -01 states that calling verification offline is inaccurate once an envelope has a delegation chain or a revocation_check member, and -02 section 5.2 defers ancestor retrieval, DID resolution and revocation lookup. My draft does not specify revocation at all. Both of us therefore recompute a verdict against state that may have changed since, and neither document says so where a reader would need it.
>> 
>> So the question for the charter text is whether verifiable means the arithmetic recomputes, or whether it recomputes against state the verifier can check at audit time.
>> 
>> Henri Sirkkavaara
>> Vaara - Accountable Autonomy
>> Built to see over the noise.
>> vaara.io <https://vaara.io/>Helsinki, Finland
>> 
>> On Tuesday, September 22nd, 2026 at 13:51, Lars Kersten Kroehl <lars=[e-mail]> wrote:
>>> Henri, Mirja —
>>> 
>>> The verifiability sentence only holds if a second party can recompute the records it covers. Without that, a record shows only that its issuer asserted a verdict. For a record of what a user permitted, the issuer is the agent itself.
>>> 
>>> By recompute-determinism I mean this: an independent verifier, given the same inputs, produces the same verdict and the same reason code, without trusting whoever issued the record. If two verifiers can derive different verdicts from the same record, the record settles nothing about which verdict was correct.
>>> 
>>> On the open user-intent question: what matters at audit time is what the user permitted. We encode that as a machine-evaluable mandate and check each transaction against it. The verdict recomputes, so the record does not depend on the agent to report it honestly. Our published draft, draft-kroehl-agentic-trust-aae-02, produces PERMIT, DENY and PENDING verdicts in this form.
>>> 
>>> Whatever term the charter settles on for "user intent", it has to be recorded in a form a reader can recompute. Otherwise the verifiability sentence does not apply to it.
>>> 
>>> Lars Kroehl
>>> MolTrust
>>> 
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> 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]