[SCITT] Re: New individual submission: draft-mih-scitt-agent-action-capsule-00

[Iman Schrock <[e-mail]>]

Steven, Tom, all,

Great thread — the pieces are composing into one chain, and I think there's
a clean fourth leg that's implied here but not yet named as its own SCITT
statement profile.

Mapping what's on the table:
- permit-profile / agentroa route-authorization → CAN: permission was
granted (the workload may act).
- EMILIA authorization receipt → WHO: a specific, named human (or a quorum
of humans) authorized this exact action — portable, offline-verifiable, no
trust in the operator.
- Steven's Capsule → WHAT: a digest-committed record of what the agent
actually did, verdict-complete.
- Tom's GAR → the kernel-side enforcement/audit log that can produce these
statements.

So the chain reads: permit (CAN) → EMILIA receipt (WHO authorized —
accountable human) → Capsule (WHAT was done) → GAR (audit log). Four
complementary profiles over one transparency service, each answering a
different question.

The "WHO" leg is worth naming distinctly because "authorization" is
overloaded: permit/agentroa establish machine/scope permission; EMILIA
establishes that an accountable named human approved the exact action. Both
are needed; they're not the same statement.

Like the Capsule, the EMILIA receipt is verdict-complete (a missing or
refused human approval is itself a signed, provable event) and
byte-deterministic (JCS / RFC 8785), and it rides as a SCITT Signed
Statement the same way: COSE_Sign1 over the receipt's JCS-canonical payload
(Ed25519), registered via SCRAPI. Cross-language verifiers (JS/Python/Go)
agree on a shared vector set, and there's a runnable register → receipt →
verify demo.

- Profile:
https://github.com/emiliaprotocol/emilia-protocol/blob/main/docs/EP-RECEIPT-SCITT-PROFILE.md
- Runnable end-to-end:
https://github.com/emiliaprotocol/emilia-protocol/blob/main/examples/scitt/ep-receipt-scitt-end-to-end.mjs
- I-D: draft-schrock-ep-authorization-receipts (
https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/)

I'd genuinely welcome being told where the "WHO" is already served by
permit/agentroa, or where an EMILIA statement composes badly with the
Capsule. And +1 to naming the cluster — if an agentproto BOF is forming, a
shared CAN / WHO / WHAT / audit decomposition might be a useful frame to
walk in with.

Thanks,
Iman Schrock
EMILIA Protocol · [e-mail]

On Wed, Jul 01, 2026 04:14 AM, toshiyuki sato <[e-mail]> wrote:

> Hi Steven,
>
> Thank you for this — the Agent Action Capsule addresses exactly the right
> problem at the SCITT layer, and the design choices (verdict-complete audit
> trail, byte-level determinism via JCS) are ones we've independently arrived
> at in the SOOS project from the kernel side.
>
> I wanted to introduce a related set of drafts that may be useful context
> for the Capsule profile, specifically around what produces the statements
> that a Capsule-based transparency service would receive.
>
> The SOOS project (draft-sato-soos-*, 19 Internet-Drafts submitted to
> Datatracker ahead of the July 6 cutoff) defines a governance kernel
> architecture for agentic AI systems. The piece most directly relevant here
> is GAR (Governance Audit Record, draft-sato-soos-gar): a causally-ordered,
> append-only governance log produced by the kernel's Governing Enforcement
> Component (GEC), structured as a semantic convention layer on
> OpenTelemetry. GAR Session Blocks — Merkle-rooted, KIA-signed collections
> of Authority Lifecycle Events — are the natural upstream producer of SCITT
> Signed Statements: the Session Block Merkle root and KIA signature map
> directly onto the SCITT issuer-signed statement model.
>
> Two points of contact with the Capsule design:
>
> 1. Verdict completeness. GAR records every Authority Lifecycle Event
> including enforcement refusals (ALE-059: ACD_VALIDATION_FAILED), policy
> blocks, and HEM escalations — not just successful actions. The same
> survivorship-bias argument you make for Capsules applies at the kernel
> level: a gate firing is itself a governance event and must be in the audit
> record.
>
> 2. The producer/consumer boundary. The Capsule profile defines what a
> SCITT statement for agent actions looks like at the transparency service
> layer. GAR defines what the kernel-side enforcement log looks like before
> it becomes a SCITT statement. A SOOS kernel emitting GAR Session Blocks as
> SCITT Signed Statements would give Capsule verifiers a kernel-attested,
> tamper-evident source — the GEC signature (KIA private key, RFC 9334
> attester model) provides the root of trust that the Capsule's digest
> commitment relies on.
>
> I've also been following the permit-profile and
> agentroa-route-authorization work you reference. GAR's ACD compliance
> handshake events (draft-sato-soos-acd) sit between those authorization
> records and the execution record your Capsule captures — pre-execution
> compliance disclosure → Capsule execution record → GAR audit log is a
> complete chain.
>
> Full draft index: https://soosproject.ai/drafts
> GAR specifically: https://datatracker.ietf.org/doc/draft-sato-soos-gar/
>
> Happy to discuss further on-list or at Vienna if you're attending.
>
> Best regards,
> Tom Sato
> CEO, MyAuberge K.K.
> [e-mail]
> https://soosproject.ai
>
> 2026年6月20日(土) 4:38 Steven Mih <steven=[e-mail]>:
>
>> Hi all,
>> Two quick updates on the Agent Action Capsule profile for SCITT, plus
>> a companion draft for review.
>> -01 is posted:
>> https://datatracker.ietf.org/doc/draft-mih-scitt-agent-action-capsule/
>>
>> The reference implementation is now public. You can reproduce the
>> byte-level determinism in about a minute:
>>
>> git clone https://github.com/action-state-group/agent-action-capsule
>> cd agent-action-capsule && pip install -e python
>> agent-action-capsule verify
>> test-vectors/pos-executed-confirmed/input.json    # ok: true
>> agent-action-capsule verify
>> test-vectors/neg-capsule-id-mismatch/input.json   # ok: false
>> (capsule_id mismatch)
>>
>> A conformant Capsule recomputes its content-address and passes; a
>> tampered one is rejected. The same vectors pass under two independent
>> implementations (Python and Go) with zero divergences. The repo also
>> has the spec source, the profile's interim registry, and
>> positive/negative vectors for every verdict class and check.
>>
>> Companion (selective disclosure): I've filed "Selective Disclosure
>> Profile for Agent Action Capsules"
>> (draft-mih-scitt-agent-action-capsule-sel-disc-00):
>>
>> https://datatracker.ietf.org/doc/draft-mih-scitt-agent-action-capsule-sel-disc/
>>
>> It does per-field selective disclosure of the JSON Capsule payload
>> (salted-hash commitments, decoy digests, disclosed [salt, name, value]
>> triples), following SD-JWT (RFC 9901), with JCS (RFC 8785) as the
>> canonicalization: already the base profile's canonical form. SD-CWT
>> (draft-ietf-spice-sd-cwt) is the CBOR sibling, and the profile stays
>> aligned with that SPICE work. It targets one signed Capsule serving
>> verifiers with different entitlements: a regulator gets every field,
>> an auditing partner only the disposition, without re-signing.
>> Disclosable fields are enumerated; the fields the base verifier needs
>> for the dispatched-vs-confirmed distinction are non-concealable.
>>
>> Two questions I have and welcome views:
>> fit with SCITT registration policy for these statement profiles; and
>> whether the companion should track SD-CWT (draft-ietf-spice-sd-cwt)
>> more tightly, rather than the SD-JWT / JSON model it follows now.
>>
>> Earlier asks still stand and are now in the implementation: the
>> provisional protected-header claim set (Section 3.1) and open/deferred
>> items via chained superseding Capsules (Section 5.4.4).
>>
>> Both are individual submissions, not WG documents and not RFCs; the
>> substrate (SCITT architecture, COSE Receipts) is itself pre-RFC. Code
>> components are royalty-free.
>>
>> Steven Mih
>> Action State Group, Inc.
>> On Sat, Jun 13, 2026 at 1:03 PM <[e-mail]> wrote:
>> >
>> > Hello SCITT Working Group,
>> >
>> > I've submitted a new individual draft, "An Agent Action Capsule Profile
>> for SCITT" (draft-mih-scitt-agent-action-capsule-00).
>> >
>> > The profile defines a SCITT statement profile for the "did" layer of AI
>> agent actions — a digest-committed record of what an agent actually did,
>> structurally binding the observed response so that a dispatched attempt
>> cannot be presented as a completed effect. It's intended to complement, not
>> overlap, the pre-execution authorization work already in this space (e.g.
>> draft-munoz-scitt-permit-profile and
>> draft-nivalto-agentroa-route-authorization): authorization records prove
>> permission was granted; Capsules record what occurred, including refusals.
>> >
>> > Two design choices I'd particularly value the group's eyes on:
>> >
>> > A Capsule on every verdict. Refusals, blocks, and timeouts are recorded
>> as affirmative evidence, not just successes — so the audit trail isn't
>> survivorship-biased and a gate firing is itself provable.
>> >
>> > Byte-level determinism. Verification relies strictly on JCS
>> canonicalization and exact decimal strings, reproducible by any
>> payload-bearing verifier without model re-prompting or heuristics.
>> >
>> > The two areas where I'd most welcome feedback are the provisional
>> protected-header claim set (Section 3.1) and the handling of open and
>> deferred items via chained superseding Capsules (Section 5.4.4).
>> >
>> > The draft is informed by an active reference implementation. IPR
>> disclosures for this draft have been filed and are being processed by the
>> datatracker; the declared licensing terms are royalty-free.
>> >
>> > I'd be glad to walk through the profile briefly if there's interest
>> from the group or the chairs. Feedback on-list is very welcome.
>> >
>> > Respectfully,
>> > Steven Mih
>> > Action State Group, Inc.
>>
>> --
>> SCITT mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
>
> --
>
> Tom Sato
> 佐藤俊之
> 代表取締役CEO
> マイオーベルジュ株式会社
> 090-6315-1325
> [e-mail]
> --
> SCITT mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>