[SCITT] Re: draft-noa-scitt-ai-agent-receipt-00: physical-completion non-claim for agents acting on external systems

[Ordeliya Support <[e-mail]>]

Dear Carlos, Iman, Steven, and the SCITT list,

Thank you for the detailed and constructive feedback.

I agree with the central distinction raised in this thread: pre-execution
authorization, controller-reported outcome, and physical completion are
three separate claims. A shared action digest can correlate records, but
digest equality alone proves none of those claims. Where a signed outcome
is used, the relationship between the outcome signer and the request or
authorization signer must also be explicit.

I am currently away with limited email access and will return on 15 August.
Rather than provide a rushed response, I want to record the exact
implementation status as of 23 July 2026.

The published -00 draft remains the current specification. Its defensible
claim is deliberately narrow: it binds recorded fields to an
issuer-authenticated, signature-verifiable, tamper-evident record. It does
not establish that recorded inputs were true or complete, that a policy was
adequate or in force, that a controller succeeded, that a physical effect
occurred, or that the person named in an approval field authorized that
exact action before execution.

The public reference implementation has advanced beyond the
implementation-status text in -00:

- It implements signed, JCS-canonicalized, hash-chained receipts, offline
verification, identity binding, and COSE_Sign1 encoding and verification.
- It now emits and verifies the RFC 9864 Ed25519 algorithm identifier `-19`
and rejects the legacy polymorphic `-8` identifier.
The migration note in Appendix A of -00 is therefore stale.
- The repository reports TypeScript and separately implemented Python
verification against the same public conformance corpusin CI.
- Go, Rust, and C# verifier implementations are present in the repository,
but I am not claiming that all of them currently have the same CI-backed
conformance coverage or that external interoperability across all
implementations has been demonstrated.
- An optional deterministic policy-commitment and replay implementation
also exists. It is separate from the base receipt claim and remains outside
the normative scope of -00. It does not prove that recorded inputs were
true or that the referenced policy was adequate or actually in force.

The public repository also contains a separate alpha implementation of the
pre-execution approval flow. It includes signed Hold and Decision
artifacts, pre-dispatch Execution Grant reservation, post-dispatch evidence
artifacts, and an offline gate-boundary evidence verifier. This provides
implementation experience for the authorization claim, but it is not yet
the claim model proposed in this thread and it does not prove a downstream
or physical outcome.

  Public implementation:
  https://github.com/NordenSoft/noa

  Public CI example:
  https://github.com/NordenSoft/noa/actions/runs/29955229764

  To be explicit about what is not implemented today:

  - `controller_reported_outcome` is not yet part of the receipt profile;
  - `physical_completion` is not yet represented as a machine-readable
claim or non-claim;
  - the proposed outcome-signer relationship is not yet represented;
  - the proposed purpose-specific negative vectors are not yet in the
public conformance corpus; and
  - we have not published a reproducible demonstration of registration with
an external SCITT Transparency Service.

  In the current approval-evidence implementation, `EXECUTED` records
dispatch or attempt at the governed gate boundary. It does not attest
controller acceptance or physical completion.

  A receipt may therefore remain cryptographically valid while being
insufficient for a particular consumer intent, such as physical-completion
proof or independent-outcome proof. I believe that distinction should
become explicit and machine-checkable in the next revision.

The mobile application is scheduled to go live on 15 August 2026.

For the next revision, I plan to:

1. separate pre-execution authorization, controller-reported outcome, and
physical completion;
2. define the trust semantics and failure behavior for each claim
independently;
3. make signer relationships machine-readable when signed outcome evidence
is present;
4. add purpose-specific negative conformance vectors;
5. define the shared action-digest construction rather than assume
equivalence with the current `action.paramsHash`;
6. clarify the relationship between the native receipt signature and the
outer COSE_Sign1 envelope;
7. resolve the current policy-identity inconsistency in the base payload;
8. clarify that a self-signed chain verifies the continuity of the
presented sequence but cannot prove that an unseen tail does not exist
without a trusted checkpoint or external witness;
9. replace the term “non-repudiable” with the narrower
“issuer-authenticated” or “signature-verifiable” wording; and
10. update the stale algorithm-migration implementation note.

The proposed field names remain contributions for discussion rather than
agreed SCITT or IETF terminology. I will provide a point-by-point technical
response and proposed -01 text after I return.

Thank you again for the careful review and for contributing concrete field
and negative-vector proposals.

Best regards,

Tora Toraman
Noa
Copenhagen / Denmark
 Author of draft-noa-scitt-ai-agent-receipt


Steven Mih <[e-mail]>, 7 Tem 2026 Sal, 07:05 tarihinde şunu
yazdı:

> Tora, Carlos, Iman, all,
>
> Strong thread. Controller-reported outcome, physical completion, and
> Iman's pre-execution authorization are three genuinely distinct claims
> sharing one action digest — and stating each as a field the verifier
> renders, with a matching negative vector, is the right discipline.
>
> Happy to help turn those non-claims into shared conformance vectors so the
> vocabulary lands cleanly rather than fragmenting across profiles. Several
> of us will be at IETF 126 if it's easier in person.
>
> Best,
> Steven
>
> On Mon, Jul 06, 2026 12:32 PM, Iman Schrock <team=
> [e-mail]> wrote:
>
>> Carlos, Tora, all,
>>
>> The two-fact split is right, and there is a third fact that sits in front
>> of both: whether a named human authorized this exact action before it ran.
>> Controller-reported outcome, physical completion, and pre-execution
>> authorization are three different claims. They can share one action digest
>> as a join key, but digest equality proves none of them, and each should
>> fail independently.
>>
>> Both suggestions have running precedents in EMILIA Protocol, offered as
>> vocabulary to reuse rather than fragment:
>>
>> 1. Machine-checkable non-claims: our conformance suite carries a named
>> negative case, attribution_substituted_for_authorization, where a validly
>> signed post-execution record is refused when presented as pre-execution
>> authorization. A non-claim stated as a field the verifier renders is the
>> same discipline, and physical_completion defaulting to none deserves a
>> matching negative vector: a receipt presented as physical proof must be
>> rejected with the failing check named.
>>
>> 2. Signer relationship: EP-EXTERNAL-VERIFICATION-STATEMENT-v1 exists for
>> the same forensic trap on the verification side. An independent party signs
>> what it checked under its own key, and same-party evidence cannot silently
>> stand in for independent proof. Stating the outcome signer's relationship
>> to the authorization signer in the receipt is the emitting-side twin of
>> that, and it should be a required field, not prose.
>>
>> Happy to contribute the negative-vector text. The framing several of us
>> have converged on elsewhere (same action digest, different claims,
>> independent failure) covers this case without any profile expanding its
>> mandate.
>>
>> Iman Schrock
>> EMILIA Protocol
>>
>> On Mon, Jul 6, 2026 at 11:24 AM Carlos Hernandez <[e-mail]>
>> wrote:
>>
>>> I sent this to the authors directly and am reposting to the list for
>>> the archive and wider input.
>>> Carlos Hernandez
>>> --
>>>
>>> Hi Tora, and the list,
>>>
>>> I read draft-noa-scitt-ai-agent-receipt-00 with interest. The restraint
>>> in
>>> the abstract is the right instinct: the profile signs "what an agent did,
>>> under which policy, with what verdict," and explicitly does not claim the
>>> recorded inputs were true or that any real-world outcome followed.
>>>
>>> One suggestion. For agents whose authorized action reaches an external
>>> controller or an actuated system (a robot action server, an industrial
>>> controller, a physical process), the single phrase "real-world outcome"
>>> actually collapses two distinct facts that a receipt consumer will want
>>> to
>>> keep apart after an incident:
>>>
>>>   1. what the downstream system *reported* as its terminal status
>>>      (controller-reported outcome), and
>>>   2. whether the intended physical effect actually occurred
>>>      (physical completion).
>>>
>>> These are not the same claim, and conflating them is exactly the
>>> overclaim
>>> this profile is otherwise careful to avoid. A controller reporting
>>> "succeeded" attests success under its own semantics; it does not prove
>>> the
>>> object moved or the scene was safe.
>>>
>>> Two small, in-scope things this profile could do without expanding its
>>> mandate:
>>>
>>>   - carry an explicit, machine-checkable non-claim field (e.g. a
>>>     physical_completion claim defaulting to "none") rather than leaving
>>> the
>>>     limit in prose, so a verifier renders it rather than a human
>>> inferring it; and
>>>
>>>   - where the action outcome is itself signed, let a receipt state the
>>>     relationship between the outcome signer and the request/authorization
>>>     signer (same administrative party vs. independent party). Same-party
>>>     evidence presented as independent proof is a common forensic trap.
>>>
>>> Happy to contribute concrete field text if useful. I've been working on
>>> the
>>> narrow case of agent-to-controller action handoffs and would rather see
>>> the
>>> vocabulary land cleanly here than fragment across profiles.
>>>
>>> Carlos Hernandez
>>>
>>> --
>>> SCITT mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>
>>
>> --
>> Iman Schrock
>> Founder
>> EMILIA Protocol
>> emiliaprotocol.ai | [e-mail]
>> --
>> SCITT mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>