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

[Iman Schrock <[e-mail]>]

Mirja, Henri,

One distinction that might help the charter wording is to avoid making
“verifiable” a single yes-or-no result.

A relying party may need to check three different things: that the record
is authentic, that its verdict can be recomputed from the named inputs, and
that any external state it relied on, such as revocation or delegation
status, was fresh at a stated time. Attestation can support the first;
recomputation supports the second; neither alone establishes the third.

In EMILIA we keep those results separate. Perhaps Deliverable 3 could
require the record to identify which checks were performed and what
external state and time they depended on, without prescribing one
verification mechanism.

Best,
Iman


On Wed, 23 Sep 2026 09:38:11 +0000, Henri Sirkkavaara <[e-mail]>
wrote:

Mirja, Yes, it would help, as long as attestation sits beside recomputation
rather than standing in for it. The sentence I would want in deliverable 3
also answers the question in my last message: a record is verifiable if a
relying party can recompute its verdict from the record and published keys
without trusting the issuer, and the record names the external state that
verdict depended on, such as revocation or delegation status, and as of
when it was read. Henri Sirkkavaara Vaara - Accountable Autonomy Built to
see over the noise. vaara.ioHelsinki, Finland On Tuesday, September 22nd,
2026 at 16:31, Mirja Kuehlewind (IETF) <ietf=[e-mail]>
wrote: > 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]