An Agent Action Capsule Profile for SCITT

3.1. Producer Envelope wire profile

A Producer Envelope is a tagged COSE_Sign1 [RFC9052] object (CBOR tag 18, [RFC8949]). It signs the Capsule's stable identity, not the Capsule JSON. Its attached payload MUST be the raw 32 bytes obtained by decoding the Capsule's 64-character lowercase hexadecimal capsule_id. The payload MUST NOT be hexadecimal text or a JSON serialization.¶

The protected header map MUST contain exactly these three entries:¶

The unprotected header map MUST be empty in a bare Producer Envelope. The signature MUST be a 64-byte Ed25519 signature over the COSE Sig_structure with context Signature1, the encoded protected map, an empty external AAD, and the attached payload.¶

A Capsule MAY have zero, one, or multiple Producer Envelopes. Each envelope is an independent object and MUST verify independently against the same Capsule ID. Envelopes are not embedded in the Capsule-ID preimage. Adding, removing, or replacing an envelope therefore never changes capsule_id. This document does not mandate a container representation for carrying a Capsule together with its envelopes.¶

3.2. Issuer Binding

Successful Producer Envelope verification proves that the holder of the private key corresponding to the protected kid signed the Capsule ID. It does not prove that this key is authorized for the Capsule's operator, developer, or action. Key authorization is caller policy and is deliberately separate from the cryptographic verdict. A verifier MUST return the authenticated public key so the caller can apply an allow-list, certificate, DID, SPIFFE, or other authorization policy without changing this wire profile.¶

3.3. Registration and Receipts

A bare Producer Envelope is not an [RFC9943] Signed Statement. Its protected map intentionally contains only the three entries in Section 3.1, whereas an RFC 9943 Signed Statement additionally requires protected CWT iss and sub claims. A conforming Transparency Service therefore MUST NOT treat a bare Producer Envelope as an RFC 9943 Signed Statement.¶

To make a Capsule ID transparent, a registrar creates a distinct RFC 9943 Signed Statement whose attached payload is the same raw 32-byte Capsule ID and whose content type is application/agent-action-capsule-id. That registration statement MUST satisfy every RFC 9943 protected-header requirement, including CWT iss and sub. The returned Receipt binds the registration statement to the service's append-only log. It does not replace or modify any Producer Envelope and does not by itself authorize a Producer Envelope key.¶

Receipt format, Merkle-tree proof construction, and proof verification are SCITT substrate concerns defined by reference to [I-D.ietf-cose-merkle-tree-proofs] and an applicable receipt profile such as [I-D.ietf-scitt-receipts-ccf-profile]. Verification is compositional: verify the Capsule ID, verify each Producer Envelope independently, require the SCITT registration statement payload to equal that raw Capsule ID, then verify its Receipt under a trusted Transparency Service key. A verifier MUST NOT report attestation_mode: "anchored" unless all applicable registration-statement and Receipt checks succeed.¶

3.4. Outcomes

An asynchronously observed consequence, such as a reversal, dispute, correction, or confirmation, is recorded as a new Capsule with its own Capsule ID. It MAY carry its own Producer Envelopes. Correlation uses payload fields such as action_id, decision_id, external_ref, and chain; it does not mutate the original Capsule. The log remains append-only and the original identity remains immutable.¶

5.1. Identity and parties

For a vintage format-2 Capsule, canonicalization_id MUST be absent. Its Capsule ID is verified by removing capsule_id and chain, applying the legacy absent-field normalization, then applying JCS and SHA-256. This path is verification-only. A producer MUST NOT emit a new format-2 Capsule.¶

Monetary and quantity values are subject to the exact-decimal-string requirement in Section 2.¶

5.2. Configuration epochs

A configuration epoch is the contiguous sequence of Capsules produced by one agent configuration — one model version, one policy-manifest version, one runtime variant — before any of those configuration dimensions changes. Epochs exist because a model swap or policy revision is a behavioral discontinuity; without a recorded epoch boundary, pre- and post-change history blend silently and a verifier cannot scope a query to "the current configuration."¶

5.3. Effect Record and the confirmed-effect binding

The Effect Record describes the side effect the action committed. Its status member takes one of five values:¶

The confirmed-effect invariant: a producer MUST NOT emit status: "confirmed" without a response_digest over the actually observed response. A verifier MUST treat confirmed with a missing response_digest as a verification failure. This is the byte-level mechanism behind the may/did distinction: "confirmed" is an observed result, never a promise.¶

The Effect Record also carries the logical type (registry-governed, Section 12), an optional external_ref join key for later outcomes, and an irreversibility_class — an ordered consequence enumeration (two_way, one_way_recoverable, one_way_consequential, one_way_terminal; registry-governed, Section 12).¶

The Effect Record additionally carries effect_attestation: WHO vouches for the effect's execution — the evidence grade of the effect claim. The vocabulary is registry-governed (Section 12; Specification Required), seeded with two values:¶

Validity is checked against the assurance effect_mode (Section 5.4):¶

The planned carve: effect.status: "planned" asserts no execution, so effect_attestation MUST be absent — there is nothing to grade, and a phantom grade would poison grade-based queries. It becomes REQUIRED the moment dispatch occurs.¶

The matrix is total over the effect.status values of Section 5.3. An effect.status of failed (the effect was dispatched and the runtime reported a failure; state known) derives effect_mode: "dispatched_unconfirmed" — the effect was dispatched and its result, though a failure, was not gate-confirmed; therefore effect_attestation is REQUIRED. reverted (a previously-committed effect was undone) likewise derives effect_mode: "dispatched_unconfirmed" and REQUIRES effect_attestation; the underlying committed effect it reverses is correlated separately via external_ref / decision_id (the Effect Record fields, Section 5.3), not by a distinct effect_mode. So every effect.status other than planned (carved above) and the no-effect case (not_applicable) requires effect_attestation.¶

Consumers MUST treat an unregistered or unrecognized effect_attestation value as no stronger than runtime_claimed; unknown values are informational, never a verification failure, and unknown never grades up. The grade is digest-committed in the Capsule payload and is available to any payload-bearing verifier, distinguishing gate-observed execution from runtime-claimed execution. It is not copied into a Producer Envelope header.¶

References to external authorization records carried in the Effect Record (for example, permit receipts per [I-D.munoz-scitt-permit-profile], or machine mandates) are typed digest references per [I-D.mih-sokolov-scitt-payload-binding]'s Typed Digest References section, with artifact types drawn from the CPB Artifact Type registry. Cross-profile comparability of digest values (comparable only under compatible declared digest contexts; otherwise indeterminate/deny, never equal-looking-hex) follows that document's Cross-Profile Comparability subsection.¶

NOTE: docs/interop/aac-aep-scitt-digest-binding-vector.json pins a machine-checkable positive/negative demonstration of this Cross-Profile Comparability rule across AAC, AEP, and SCITT under the profile label urn:action-state:aac-aep-scitt:digest-binding:2026-07-02.¶

This profile's own chain.parent_capsule_id, reason_digest, evidence_digest, and external_ref fields are a distinct concept from the typed digest reference above: they are bare intra-profile digests and join keys, either a current JSON digest or an opaque correlation string, not {type, digest_alg, digest} objects citing an external artifact by registered artifact type. They MUST NOT be interpreted as CPB typed digest references. Only the external-authorization references described in this paragraph use the CPB typed-reference mechanism.¶

5.4. Assurance

Every Capsule carries an assurance object stating, as independently-rederivable claims: attestation_mode ("self_attested" or "anchored"), effect_mode ("not_applicable", "dispatched_unconfirmed", or "confirmed"), and ledger_mode ("standalone", "chained", or "anchored"). ledger_mode records the custody tier of the record: "standalone" is a lone Capsule (no chain linkage); "chained" is a Capsule whose hash-chain linkage to a predecessor is present and intact; "anchored" is a chained Capsule whose chain root has additionally been committed to an independent transparency log. A verifier rederives ledger_mode from the bytes it can check — "standalone" versus "chained" from the presence and integrity of the hash-chain linkage, and "anchored" only after it verifies an inclusion proof against a trusted log key — and the three tiers are ordered standalone < chained < anchored for overclaim detection. A producer MUST NOT record an assurance mode it did not achieve; a verifier rederives each mode from the evidence present and reports any overclaim.¶

5.5. Disposition and the verdict reason-class

A Capsule's disposition block records how the decision was disposed:¶

• decision (REQUIRED): "accept", "reject", "needs_input", or "deferred" (registry-governed, Section 12).¶

• approver (REQUIRED): a closed enum, exactly "human", "policy", or "counterparty". The value domain is fixed by this specification (not registry-governed); an unknown approver value is not a conforming Capsule. Unlike the registry-governed vocabularies of this document (Section 12), approver stays a closed three-member enum after this addition — never a registry an implementation is expected to extend by registration.¶

• human_disposed (REQUIRED, boolean): the honest in-the-loop flag — true ONLY when a human actually acted. A policy auto-approval is false. human_disposed: true REQUIRES approver: "human"; a producer MUST NOT claim a human disposed what a policy did.¶

• authority (OPTIONAL): an opaque reference to the authority under which a non-human disposition acted. A conforming Capsule carries at most the reference, never the authority's internal structure.¶

• verdict_class (OPTIONAL): the terminal-verdict reason-class (Section 5.5.1). It is RECOMMENDED for any non-executed verdict, where it carries the terminal reason; it is legitimately absent for a clean executed verdict (which has no reason-class, mirroring an absent reason_digest).¶

• reason_digest (OPTIONAL): a JSON digest (Section 2) of a structured, private reason object — machine-readable members such as the constraint identifier, the threshold, and the observed value; never free prose — so two engines attesting the same refusal produce the same digest. The member is absent (not a digest of an empty object) when a verdict has no reason, such as a clean "executed".¶

• expiry_policy (OPTIONAL; deferral dispositions only): a digested {ttl_seconds, on_expiry} object — ttl_seconds is an integer count of seconds, never a duration string, and on_expiry is "expired" or "escalated". ttl_seconds is evaluated against the deferral Capsule's registration time — the timestamp field inside the digest commitment — not the Transparency Service receipt time, and not a consumer's local wall clock; a named clock basis is what makes the expiry computation deterministically reproducible, so any verifier derives the same elapsed-time result from the record's own bytes. The deferral's frozen summary is a digest-committed, content-side layer written once at deferral time; it MUST NOT be regenerated.¶

• approver: "counterparty" (see Section 5.4.1) records that a counterparty to a cross-party exchange, rather than this operator's own human or policy, disposed the decision. The honesty invariant above is unaffected: human_disposed: true still REQUIRES approver: "human", so a counterparty disposition is never claimed as human-in-the-loop.¶

8.1. Constraint Records

A Constraint Record is the public verdict of one deterministic check that ran against the action. It carries only sanitized categories — an id, optional check_type and method labels, a result of "pass" / "fail" / "n/a", severity, a blocking flag recording whether the check actually gated this decision, and an optional evidence_digest (a JSON digest, Section 2) binding the verdict to the private evidence the check evaluated. The content a check evaluated MUST NOT appear in the public record; it is bound by digest only. The check's predicate, evidence schema, and thresholds live in the producer's manifest.¶

Every recorded result MUST be the output of a deterministic predicate over disclosed or digest-committed evidence. The live decision path MUST NOT re-prompt a model to make a check pass, and a verifier MUST NOT re-prompt a model to "re-check" one: re-running a non-deterministic check is not verification.¶

Constraint id, check_type, and method values are lowercase snake_case categories. New values follow the namespacing convention of Section 9.1.¶

8.2. Class 2 verification

The checks below are manifest-aware: they require the producer's constraint manifest and the private evidence a Constraint Record binds by digest. A Class 2 verifier performs them in addition to the complete Class 1 set (Section 6); their results never weaken a Class 1 result — they extend it.¶

1. Constraint evidence-schema check: for each Constraint Record (Section 8.1) carrying an evidence_digest, confirm the bound evidence conforms to the manifest's evidence schema for that constraint id and that the recomputed digest matches; a mismatch is a failure.¶

2. Threshold checks: confirm that manifest-sourced thresholds were applied as the manifest states.¶

9.1. Namespacing convention

Three vocabularies are deliberately not registry-governed — constraint id/check_type, compliance.framework_tags, and assurance.sources[].kind — because their value space is producer-local by nature. Bare names (no namespace separator) are reserved for the values seeded in this document; any party introducing a new value MUST namespace it with a URI or reverse-DNS prefix (for example, com.example.margin_floor). A bare, unseeded name is non-conforming for a producer; a verifier still treats it as informational.¶

9.2. Selective Disclosure

The base confidentiality posture of this profile is whole-envelope: a producer discloses a Capsule by sharing its full payload, or withholds it entirely. Sensitive content not carried in the envelope leaves no on-wire indicator of its existence. This whole-envelope posture is sufficient for the common case where the unit of disclosure is the Capsule as a whole.¶

For cases in which a producer must reveal a subset of payload fields to a verifier while concealing both the values and the existence of unrevealed fields, a per-field selective-disclosure mechanism is needed. This profile reserves an extension point in the Capsule payload for such a mechanism. The intended field-level technique follows the SD-JWT selective-disclosure model [RFC9901] — salted-hash commitments over JCS-canonicalized arrays — because the Capsule payload is JSON; it is written to stay aligned with SPICE's SD-CWT [I-D.ietf-spice-sd-cwt] (the CBOR sibling) for SCITT-ecosystem consistency.¶

The complete normative profile of this mechanism — including the commitment encoding, disclosure syntax, and verifier checks — is defined in the companion Internet-Draft [I-D.mih-scitt-cpb-selective-disclosure]. That companion is a CPB payload-class document; the mechanism is payload-class-generic. This profile (AAC) retains only the eligibility-policy annex: the declaration of which AAC payload fields are eligible for selective disclosure and which are non-eligible because this profile's own verifier requires their values in clear.¶

Implementations of this profile version MUST NOT generate or interpret selective-disclosure payload structures unless they additionally implement [I-D.mih-scitt-cpb-selective-disclosure]: the extension point is defined only in that companion, and no conformance claim or verification behavior is defined for it in this document.¶

12.1. New registries

Every registry requested below governs a vocabulary that lives entirely in the Capsule JSON. A SCITT-generic Transparency Service does not need to parse those values because registration, inclusion, and Receipt issuance operate on the separate SCITT registration statement. The media-type registrations are addressed separately in Section 12.3. This profile requests no new COSE header parameter or CWT claim registry; the new registries here are payload vocabularies only.¶

IANA is requested to create a new registry group, "Agent Action Capsule Parameters", containing the seven registries below. The registration policy for each is Specification Required ([RFC8126], Section 4.6).¶

Specification Required is chosen deliberately. The threat it answers is a vocabulary value whose meaning is defined only inside a closed product — two verifiers would then disagree on what the value means, and the interoperable, falsifiable-from-the-record property this profile depends on would erode. The mitigation is the policy's publicly-available-spec requirement: a value enters the shared vocabulary only once its semantics are pinned in a specification any implementer can read. Accordingly, for each registry the designated expert approves a registration when (1) the citing specification defines the value's semantics precisely enough that two independent implementations would apply it identically — for verdict_class, including its dispatch consequence and its effect_mode pairing under Section 5.5.2; (2) the value's meaning is not already expressible by an existing registered value; and (3) the citing specification is publicly available.¶

Binding invariant for all seven registries: verifiers MUST treat unregistered values as informational and MUST NOT reject a Capsule for carrying one. Registration governs shared meaning, never acceptance.¶

Initial contents are the seeded values of this document, verbatim:¶

1. "verdict_class" registry (Section 5.5.1): executed, blocked, hitl_dispatched, denied, timeout, errored, engine_failure, deferred, needs_decision, expired, escalated, resolved, epoch_boundary. The deferred token's semantics are OWNED by this registry; the entry of the same spelling in the "disposition.decision" registry is a cross-reference to it. The epoch_boundary token denotes an administrative Capsule (action_type: "fyi") that marks a configuration-epoch transition (Section 5.2.2); it REQUIRES effect_mode: "not_applicable" (no effect is dispatched by an administrative epoch record).¶

2. "disposition.decision" registry (Section 5.5): accept, reject, needs_input, deferred. The deferred entry is a cross-reference to the "verdict_class" registry, which owns the token's semantics.¶

3. "effect.type" registry (Section 5.3): write_order, send_payment.¶

4. "irreversibility_class" registry (Section 5.3; ordered by ascending consequence — a registration states its position): two_way, one_way_recoverable, one_way_consequential, one_way_terminal.¶

5. "effect_attestation" registry (Section 5.3): gate_executed, runtime_claimed. The registry definition carries the grade-floor invariant of Section 5.3 — an unregistered or unrecognized value is graded no stronger than runtime_claimed; unknown never grades up — and the planned carve of Section 5.3: with effect.status: "planned" the member MUST be absent, and it becomes REQUIRED the moment dispatch occurs. Designated-expert guidance: plausible future registrations exist and are deliberately not seeded — for example, independent sensor confirmation of a claimed effect, or hardware- or TEE-anchored execution; a registration states where its grade sits relative to the seeded values.¶

6. "chain.relation" registry (Section 5.5.4): confirms, supersedes, epoch_opens. Designated-expert guidance: supersedes is the single terminal relation; confirms and epoch_opens are non-terminal relations, with epoch_opens reserved for configuration-epoch boundaries (Section 5.2.2). Additional non-terminal relations (for example, deposit-toward-open and effort-toward-open relations, or amends / contradicts) are expected future registrations, each admitted once its semantics and any verifier consequence are pinned in a publicly available specification.¶

7. "citation_purpose" registry (Section 5.5.5): acted_on, responds_to. This registry is distinct from, and never a repurposing of, CPB's own purpose field on a typed digest reference ([I-D.mih-sokolov-scitt-payload-binding]), which selects among an artifact type's registered digest contexts and is orthogonal to any role a companion profile assigns a digest within a cross-document citation. Designated-expert guidance: both seeded values name a citation whose target is outside the citing Capsule's own chain — a different producer or a different stream (Section 5.5.5); a citation to the producer's own same-stream chain parent is never expressed here. Additional values are expected future registrations, each admitted once its semantics are pinned in a publicly available specification.¶

Interim registry of record: until this document is published as an RFC, the registry of record is the REGISTRY.md file of the source specification repository, seeded with the same initial contents and the same policy; on publication the IANA registries become the registry of record. Change controller: Action State Group, Inc. (interim); the IETF on publication.¶

12.2. No new registry

• Attestation/signature algorithms: this profile defines no algorithm registry; algorithm identifiers are those of the existing IANA "COSE Algorithms" registry ([RFC9053]).¶

• Constraint id/check_type, compliance.framework_tags, and assurance.sources[].kind: no registry; governed by the namespacing convention of Section 9.1.¶

• Producer Envelopes use only existing COSE header labels alg, content type, and kid. This document requests no new COSE header or CWT claim.¶

12.3. Media Type Registrations

IANA is requested to register the Capsule JSON media type and the raw Capsule-ID payload media type in the "Media Types" registry per the templates below ([RFC6838]). The JSON representation uses the +json structured-syntax suffix of [RFC8259]. The raw identity payload has no structured-syntax suffix.¶

Agent Action Capsule media type:¶

• Type name: application¶

• Subtype name: agent-action-capsule+json¶

• Required parameters: N/A¶

• Optional parameters: N/A¶

• Encoding considerations: binary; the representation is JSON ([RFC8259]) as defined in this document.¶

• Security considerations: see Section 13 of this document.¶

• Interoperability considerations: see this document.¶

• Published specification: this document (and its successors).¶

• Applications that use this media type: producers, ledgers, transports, and verifiers recording and verifying AI agent actions.¶

• Fragment identifier considerations: as for application/json ([RFC8259]) per the +json suffix ([RFC6839]).¶

• Additional information: Deprecated alias names: N/A. Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A.¶

• Person & email address to contact for further information: the author of this document.¶

• Intended usage: COMMON¶

• Restrictions on usage: N/A¶

• Author: see the Authors' Addresses section of this document.¶

• Change controller: Action State Group, Inc. (interim); the IETF on publication.¶

• Provisional registration: yes (pending publication of this document).¶

Agent Action Capsule ID media type:¶

• Type name: application¶

• Subtype name: agent-action-capsule-id¶

• Required parameters: N/A¶

• Optional parameters: N/A¶

• Encoding considerations: binary; exactly 32 octets containing the raw SHA-256 Capsule ID represented in Capsule JSON as 64 lowercase hexadecimal characters.¶

• Security considerations: see Section 13 of this document.¶

• Interoperability considerations: see this document.¶

• Published specification: this document (and its successors).¶

• Applications that use this media type: COSE Producer Envelopes and SCITT Transparency Services registering Capsule identities.¶

• Fragment identifier considerations: N/A.¶

• Additional information: Deprecated alias names: N/A. Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A.¶

• Person & email address to contact for further information: the author of this document.¶

• Intended usage: COMMON¶

• Restrictions on usage: N/A¶

• Author: see the Authors' Addresses section of this document.¶

• Change controller: Action State Group, Inc. (interim); the IETF on publication.¶

• Provisional registration: yes (pending publication of this document).¶

14.1. Data-Admission Tiers

Producer and adapter authors MUST classify every candidate field into exactly one of the following tiers before admission:¶

1. Clear-safe — Opaque correlation handles that are joinable but non-identifying: for example, agent_name, function_call_id, invocation_id. A field is clear-safe when its value neither identifies a natural person nor carries content material. These MAY be committed in clear.¶

2. Digest-only — when a value must be provable later without being disclosed now, it MUST be committed as a digest, never in clear. This tier covers payload content: material a verifier may need to check but that must not be exposed in the record. This tier is realized by the selective-disclosure / detached-payload model (Section 9.2): the Capsule carries only a digest; content is held under deployment controls and disclosed selectively.¶

3. Never-enters — end-user identity (session identifiers, user identifiers, account handles) and secrets/credentials (tokens, keys) MUST NOT enter a Capsule, in clear or as a digest. Critical: hashing is not anonymization for low-entropy identifiers. Session and user identifiers and similar low-entropy values are recoverable by dictionary attack against their digest (see also Section 13). Therefore a digest of such an identifier is not a safe substitute — the digest re-identifies. Identity MUST be excluded, not digested. Where cross-record or cross-slot correlation of a subject is genuinely required, a pairwise or encrypted correlation identifier SHOULD be used instead of the raw or hashed user identifier.¶

14.2. Adapter Allow-List Pattern

Adapters SHOULD adopt an allow-list stance: enumerate the fields that MAY enter a Capsule (tier 1, plus tier-2 digests) and default-deny everything else. A block-list — enumerating what may NOT enter — fails open: when a runtime adds a new context field in a later version, a block-list silently admits it. An allow-list fails closed, which is the correct direction for a record that cannot be retracted once committed. Adapter authors SHOULD publish the allow-list in adapter documentation so deployers can audit admission without reading implementation code.¶

15.1. Normative References

[I-D.mih-sokolov-scitt-payload-binding]

Mih, S. and A. Sokolov, "Canonical Payload Binding: A Signed Statement Construction Profile", Work in Progress, Internet-Draft, draft-mih-sokolov-scitt-payload-binding-00, n.d., <https://datatracker.ietf.org/doc/html/draft-mih-sokolov-scitt-payload-binding-00>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

15.2. Informative References

[ERC8004]

"ERC-8004: Agent Identity Registry", n.d., <https://eips.ethereum.org/EIPS/eip-8004>.

[I-D.dawkins-scitt-ai-article50]

Dawkins, V. S., "A SCITT Profile for EU AI Act Article 50 Transparency Receipts", Work in Progress, Internet-Draft, draft-dawkins-scitt-ai-article50-00, 25 May 2026, <https://datatracker.ietf.org/doc/html/draft-dawkins-scitt-ai-article50-00>.

[I-D.emirdag-scitt-ai-agent-execution]

Emirdag, P., "AI Agent Execution Profile of SCITT", Work in Progress, Internet-Draft, draft-emirdag-scitt-ai-agent-execution-00, 11 April 2026, <https://datatracker.ietf.org/doc/html/draft-emirdag-scitt-ai-agent-execution-00>.

[I-D.ietf-cose-merkle-tree-proofs]

Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "COSE (CBOR Object Signing and Encryption) Receipts", Work in Progress, Internet-Draft, draft-ietf-cose-merkle-tree-proofs-18, 2 December 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-cose-merkle-tree-proofs-18>.

[I-D.ietf-scitt-receipts-ccf-profile]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., and A. Chamayou, "CCF Profile for COSE Receipts", Work in Progress, Internet-Draft, draft-ietf-scitt-receipts-ccf-profile-04, 24 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-receipts-ccf-profile-04>.

[I-D.ietf-scitt-scrapi]

Birkholz, H., Geater, J., and A. Delignat-Lavaud, "Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs", Work in Progress, Internet-Draft, draft-ietf-scitt-scrapi-11, 26 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-scrapi-11>.

[I-D.ietf-spice-sd-cwt]

Prorock, M., Steele, O., Birkholz, H., and R. Mahy, "Selective Disclosure CBOR Web Tokens (SD-CWT)", Work in Progress, Internet-Draft, draft-ietf-spice-sd-cwt-08, 1 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-spice-sd-cwt-08>.

[I-D.kamimura-scitt-refusal-events]

Tokachi, K., "Verifiable AI Refusal Events using SCITT", Work in Progress, Internet-Draft, draft-kamimura-scitt-refusal-events-03, 2 August 2026, <https://datatracker.ietf.org/doc/html/draft-kamimura-scitt-refusal-events-03>.

[I-D.kamimura-scitt-vcp]

Tokachi, K., "A SCITT Profile for Verifiable Audit Trails in Algorithmic Trading: The VeritasChain Protocol (VCP)", Work in Progress, Internet-Draft, draft-kamimura-scitt-vcp-03, 21 July 2026, <https://datatracker.ietf.org/doc/html/draft-kamimura-scitt-vcp-03>.

[I-D.kamimura-vap-framework]

Tokachi, K., "Verifiable AI Provenance Framework (VAP): An Architectural Framework for Evidentiary-Grade AI Decision Trails", Work in Progress, Internet-Draft, draft-kamimura-vap-framework-01, 21 July 2026, <https://datatracker.ietf.org/doc/html/draft-kamimura-vap-framework-01>.

[I-D.mih-agent-bilateral-attestation]

Mih, S., "Bilateral Agent Action Attestation", Work in Progress, Internet-Draft, draft-mih-agent-bilateral-attestation-00, n.d., <https://datatracker.ietf.org/doc/html/draft-mih-agent-bilateral-attestation-00>.

[I-D.mih-sato-agent-accountability-composition]

Mih, S. and T. Sato, "Agent Accountability: Composition and Conformance", Work in Progress, Internet-Draft, draft-mih-sato-agent-accountability-composition-00, n.d., <https://datatracker.ietf.org/doc/html/draft-mih-sato-agent-accountability-composition-00>.

[I-D.mih-scitt-cpb-selective-disclosure]

Mih, S., "Selective Disclosure Profile for Canonical Payload Binding", Work in Progress, Internet-Draft, draft-mih-scitt-cpb-selective-disclosure-00, n.d., <https://datatracker.ietf.org/doc/html/draft-mih-scitt-cpb-selective-disclosure-00>.

[I-D.munoz-scitt-permit-profile]

Munoz, C., "A SCITT Profile for Pre-Execution AI Action Authorization Records", Work in Progress, Internet-Draft, draft-munoz-scitt-permit-profile-01, 19 July 2026, <https://datatracker.ietf.org/doc/html/draft-munoz-scitt-permit-profile-01>.

[I-D.nivalto-agentroa-route-authorization]

Michalak, J., "Agent Route Origin Authorization (AgentROA): A Cryptographic Policy Enforcement Framework for AI Agent Actions", Work in Progress, Internet-Draft, draft-nivalto-agentroa-route-authorization-01, 15 April 2026, <https://datatracker.ietf.org/doc/html/draft-nivalto-agentroa-route-authorization-01>.

[I-D.rampalli-scitt-capsule-provenance-binding]

Rampalli, K., "SCITT Capsule Provenance Binding", Work in Progress, Internet-Draft, draft-rampalli-scitt-capsule-provenance-binding, n.d., <https://datatracker.ietf.org/doc/html/draft-rampalli-scitt-capsule-provenance-binding>.

[I-D.sato-soos-gar]

Sato, "The Governance Audit Record (GAR) for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato-soos-gar-06, 25 August 2026, <https://datatracker.ietf.org/doc/html/draft-sato-soos-gar-06>.

[NotarizedAgents]

"Notarized Agents: Decentralized, Verifiable AI Agent Receipts", 2026, <https://arxiv.org/abs/2606.04193>.

[RFC6839]

Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, <https://www.rfc-editor.org/rfc/rfc6839>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9053]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

[RFC9901]

Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, <https://www.rfc-editor.org/rfc/rfc9901>.

[VerifiableIntent]

Mastercard, "Verifiable Intent", n.d..