]> Council of AI (CSOAI Ltd)

London United Kingdom nicholas@csoai.org

Security SCITT transparency measurement agents This document defines the measurement capsule: a small, deterministic JSON record in which a party that is neither the subject of a claim nor a participant in the action it concerns records what the subject declared, what the measuring party observed, and the difference between the two. A capsule carries digests of its evidence, a measurement state in which "could not be checked" is a first-class outcome, and no decision, approval or authorisation. Capsules are identified by the SHA-256 of their JCS serialisation and batched under an RFC 9162 Merkle Tree Hash. The document describes their registration as SCITT Signed Statements (RFC 9943), how they refer to rather than restate receipts issued under other profiles, and one implementation, including where it does not yet match this profile.

Introduction Several individual drafts define receipts for automated actions. binds an enrolled approver key to one canonical action before execution; profiles signed action receipts, including decision receipts carrying a policy digest; defines signed, hash-chained action receipts and carries such receipts as SCITT Signed Statements; records categorical screening outcomes in agentic-payment flows. These readings are the author's; corrections from their authors will be adopted. Those receipts are issued by a party in the path of the action and answer "was this permitted, and by whom?". They are not designed to answer a different question: does what a subject publicly declares about itself (a protocol version in a registry, a signing key in an agent card, a token's deployments, an evaluation result) match what an unaffiliated reader can observe? A measurement capsule records one such comparison. It differs from an action receipt in three ways. First, its Issuer is neither the subject nor a participant in the action, and it grants no authority; where the Issuer measures itself, the capsule should say so. Second, it carries the declaration, the observation and an explicit differential, and its state may be UNCHECKABLE, which is never recorded as a pass, a failure, a zero or an absence. Third, it may reference a receipt issued under another profile by digest () but never copies its outcome, so an approver's receipt and an independent measurement of the same effect can sit in one Transparency Service without either restating the other. The closest work, , reconciles a decider's signed Decision Records against an authenticated extract of effects; a capsule records one comparison and draws no conclusion about any decision. specifies declared canonicalisation and typed digest references for Signed Statements; capsule_id () is its derived identifier under algorithm jcs with the exclusion set {capsule_id}. This document profiles content, not the SCITT architecture. The terms Issuer, Signed Statement, Transparency Service and Receipt are used as defined in , and registration follows unchanged. The author's organisation does not operate a Transparency Service. The document is Experimental because its requirements on decision fields and UNCHECKABLE () have not been shown useful by more than one implementation ().

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Declared:

What the subject, or a registry or manifest speaking for it, states about a claim, as read from bytes the measurer retrieved.

Observed:

What the measurer read from a source other than the declaring one: a live protocol exchange, a ledger's state, a signature verification or a rerun on different hardware.

Differential:

The structured difference between the two. It is data, not a judgement: "these two statements disagree" does not say which is true.

Measurer:

The Issuer of a capsule; neither the subject nor a participant in the action the claim concerns, except in a self-measurement, which the capsule SHOULD mark as such.

Evidence ladder:

An ordered vocabulary recording how strong an observation is, as distinct from what it found: STATE_PROOF_VERIFIED (a proof checked against a block header's state commitment, the header not checked against consensus), STATE_PROOF_RECORDED (kept, did not verify), OPERATOR_API (an operator's answer, no proof), UNCHECKABLE and REJECTED (an identity check failed). A label MUST NOT be upgraded; an Issuer MUST refuse to build a capsule from a source record whose label claims more than its evidence shows.

The Capsule A capsule is a JSON object with the structure below, in CDDL using the .cat control of . The inner structure of the open maps depends on kind.

any }, "declared": open-map, "observed": open-map, "differential": open-map, "sources": sources, "measurement_state": tstr .size (1..64), "authority_state": authority-none, "effect_reference": effect-reference / null, "observed_at": tdate, "correction_pointer": correction-pointer / null, "limitations": [* tstr], ? "runtime_declared": open-map, ? "runtime_observed": open-map, "capsule_id": sha256-hex } open-map = { * tstr => any } sources = { * tstr => source-value } source-value = digest / null / [* source-value] / sources digest = tstr .regexp "(sha256:)?[0-9a-f]{40,128}" sha256-hex = tstr .regexp "[0-9a-f]{64}" authority-none = "NONE: measurement only; this capsule grants" .cat " and records no execution authority" effect-reference = { "profile": tstr, "statement_digest": digest, ? "transparency_service": tstr, ? "entry_id": tstr, * tstr => any } correction-pointer = { "record_schema": tstr, "record_version": tstr, "record_sha256": digest, "supersedes_record_sha256": digest / null, "from": any, "to": any, ? ("why" / "cause"): tstr, * tstr => any } ]]>

kind fixes the inner structure of the open maps and the vocabulary of measurement_state. subject_id is an identifier (an endpoint URL, asset:product:ledger:address), not a resolvable reference. claim.statement can be true or false of the subject. differential SHOULD name the items that differ, not only a count. sources holds digests of the artefacts the capsule was derived from (signed source record, fetched documents, responses, proofs, commits) and MUST NOT carry evidence bytes, URLs or free text; any other value makes the capsule invalid. authority_state is the only member whose name concerns authority, with one permitted value. observed_at is the time of the observation, not of the build. limitations states what the measurement does not show; a capsule SHOULD carry at least one, and it is covered by capsule_id. In runtime_declared and runtime_observed (reproducibility claims), values not recorded at the time are UNRECORDED, never omitted or inferred. The implementation's seven kinds, not registered here, compare: an MCP endpoint's registry, mcp.json, server-card and payment-manifest declarations with its live initialize and tools/list answer (contract_parity); an agent card's signatures with their verification under its declared protocol version (a2a_card_signature); an issuer's list of a tokenised asset's deployments with each ledger's state (cross_ledger_supply); external indexes' listings of the measurer's own offerings with its live bytes (self_parity); a signed evaluation result with a re-run on a second runtime (cross_runtime_reproduction); and an endpoint's advertised tools at two times (tool_drift). The seventh, public_signal, records one reading of a public counter and is observation-only ().

Canonicalisation and Identifier capsule_id is the SHA-256 digest, as 64 lowercase hexits, of the JSON Canonicalization Scheme (JCS) serialisation of the capsule with capsule_id removed. Issuers MUST NOT place non-finite numbers or integers whose magnitude exceeds 2^53 in a capsule; such quantities (token supplies in base units are the common case) MUST be carried as strings. Issuers SHOULD avoid floating-point values. A capsule file stores each capsule as exactly its JCS bytes, so that a verifier can recompute capsule_id from the stored line.

Batches, Merkle Root and Index A batch is a capsule file and a batch record that commits to it. The capsule file holds one capsule per line, each followed by a single LF, sorted by capsule_id, with no duplicates. The batch Merkle root is the Merkle Tree Hash of , Section 2.1.1, with SHA-256, over the capsule_id values as 32-byte strings sorted in ascending byte order. Sorting makes the root a commitment to a set: reordering the file does not change it, so a changed root always means changed membership or content. Inclusion of one capsule is shown by an RFC 9162 audit path (Section 2.1.3), which existing tooling can verify. The batch record is a JSON object carrying at least schema, as_of, kind, n_capsules, per-state counts, merkle_root, the construction in words, the capsule file's SHA-256 and authority_state. It SHOULD state its inclusion rule and count, by reason, the source rows the rule excluded (for example, a dimension on which only one public surface spoke, where nothing was compared), so a reader sees what was not measured. An index lists each batch's record digest, root, count, signature state and timestamp state, and carries two roots under the same rule: one over the union of all capsule_id values (a duplicate across batches is an error) and one over the batch roots. The index is signed and timestamped. The implementation also chains daily indexes: each names the previous day's index by SHA-256 and root and states the number of days without an index.

Registration as a SCITT Signed Statement A capsule, batch record or index is registered as the payload of a COSE_Sign1 Signed Statement with these protected header parameters: alg (1): Ed25519 (-19) , an Ed25519 key, or another algorithm the Transparency Service's policy permits (the polymorphic EdDSA (-8) is deprecated by ); content type (3): application/vnd.csoai.measurement-capsule+json, or the same with -batch or -index before +json (); kid (4): the UTF-8 bytes of the signing key's verification method, for the implementation did:web:csoai.org#board-attestation-1 ; CWT Claims (15) : iss the Issuer, sub the batch's kind, the capsule's subject_id or a fixed index name, and iat the signing time. The payload is the JCS serialisation of the object, or its SHA-256 under the COSE Hash Envelope . With one registration per batch, inclusion is shown in two steps: capsule to batch root (the Issuer's tree), then batch record to the log (the Receipt). The implementation does not yet encode COSE, and nothing has been registered with any SCITT Transparency Service. It signs, with pure Ed25519, a canonical JSON payload pinning a record's SHA-256, root(s) and counts, and stops if the signature also verifies over an altered preimage. It submits record digests to OpenTimestamps and has recorded the index's and chain head's signed-payload digests in Rekor ; neither is a SCITT Transparency Service or issues Receipts. Moving to COSE means re-signing every record, since a COSE signature also covers the protected header.

Measurement States and the Absence of Decisions measurement_state is one string from a vocabulary defined per kind. The states in use are, by family: agreement (CONSISTENT, INCONSISTENT, UNCHANGED_AT_NAME_GRANULARITY); verification (VERIFIED, FAILED); reproduction (REPRODUCED_ITEMWISE, REPRODUCED_AGGREGATE_ONLY, NOT_REPRODUCED); reading (the evidence-ladder labels, MEASURED, PARTIAL, TOTAL_COMPLETE, TOTAL_PARTIAL); and absence and inability (UNCHECKABLE, NOT_LISTED, NOT_DECLARED, LISTED_NOT_READ, PERMISSIONED_NOT_READABLE, ISSUER_LIST_UNAVAILABLE). For every kind: UNCHECKABLE and each absence-and-inability state MUST be recorded as such and MUST NOT be mapped to a pass, failure, zero or omission; a capsule MUST be issued for it when the batch's inclusion rule covers the subject. A state asserting absence (such as NOT_LISTED) MUST be used only where the read that established it was complete; a partial read yields UNCHECKABLE, and a total MUST NOT be recorded over a partial read. INCONSISTENT says two statements disagree, not which is true, and a state MUST NOT be stronger than its evidence.

No decision or authorisation field A capsule MUST NOT carry a decision about any party's action. Apart from authority_state, no member at any depth may be named decision, allow, allowed, allowlist, hold, reject, approve, approved, approval, admit, admission, authority, authorization, authorisation, permit, permission, grant, enforce, enforcement, action, recommended_action, gate or gate_result, or an inflection of these; and no string value at any depth may be exactly ALLOW, HOLD, REJECT, DENY, APPROVE, APPROVED, ADMIT, ADMITTED, BLOCK, PERMIT or GRANT. The rule exists so that a capsule cannot be consumed as a gate; an allow or deny outcome comes from the party holding that authority. The implementation enforces it at construction and verification (renaming a source's verdict field to agreement, for example). A denylist is incomplete (REFER, an outcome in , is not on it); it is a floor, and a per-kind allowlist of member names is an open issue.

Effect reference effect_reference, when not null, names a Signed Statement issued under another profile about the same effect: the profile and revision (for example draft-schrock-ep-authorization-receipts-13), the digest of the statement, and optionally where it can be retrieved. The digest MUST be computed over the octets as registered, since a re-encoded statement has a different digest under the same signature . The referenced statement's fields, in particular its outcome, are not copied. The implementation has not yet populated this member, so this composition is a proposal, not a report.

Corrections and Supersession A capsule is never edited; any change produces a different capsule. A correction is a new capsule, in a new batch, whose correction_pointer records the schema, version and SHA-256 of the source record in which the change was made, the SHA-256 of the record it supersedes, the state before (from) and after (to), and the reason, with the fixing commit where there was one. The superseded capsule remains valid and retrievable. A change of canonicalisation or Merkle construction changes identifiers and roots without changing any measurement, and MUST be published as a new batch, leaving earlier batches in place.

Privacy Considerations sources carries only digests; the evidence stays with whoever holds it. A digest of a public document is meant to be re-identifiable. A digest of a non-public, low-entropy artefact can be recovered by guessing, so Issuers SHOULD NOT place one in sources without blinding, which the implementation does not provide; its sources are all public or its own records. subject_id can identify a service run by one person. Issuers SHOULD measure only surfaces published for machine consumption, SHOULD NOT send credentials or go beyond discovery (the MCP measurements stop at initialize and tools/list), and SHOULD offer subjects a route to request correction or exclusion. Registration is append-only, so a capsule registered in error can be superseded but not withdrawn; Issuers SHOULD review batches before registering them.

Security Considerations A valid signature on a batch record shows only that the holder of the key signed those bytes, not that any value is correct, that the instrument is sound or that the subject endorses the measurement. A verifier SHOULD recompute every capsule_id, the batch root, the record and file digests and the signature, and SHOULD reject a batch in which any capsule carries a forbidden member or value. The implementation signs with one Ed25519 key, held by a signing service reached by an authenticated request; it is not a threshold key and no claim is made about hardware protection. Compromise of the key or of the request credential allows valid signatures over false records, including a re-signed chain of daily indexes. Such a rewrite is detectable only against an anchor dated before it (a Bitcoin-attested timestamp, a Rekor entry or a Receipt), so verifiers SHOULD check anchors as well as signatures. The key is published through did:web, so its authenticity rests on DNS and the Web PKI; retired verification methods SHOULD remain resolvable. An OpenTimestamps calendar commitment shows only that calendars received a digest; only a proof upgraded to a Bitcoin attestation dates the bytes. SHA-1 Git commit identifiers in sources are locators on which no integrity claim rests. The measurer reads from one location at one time, and surfaces that should agree may be read hours apart (recorded in limitations). A VERIFIED card signature does not show who controls the key. A measurer chooses what to measure, and a batch of subjects likely to disagree would be accurate capsule by capsule and misleading in aggregate; hence the inclusion rule in batch records, and consumers SHOULD NOT aggregate state counts across batches with different inclusion rules.

IANA Considerations This document has no IANA actions. The media types in are in the vendor tree and can be registered without IETF action, which the author intends to do before any Signed Statement is registered under them.

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. RFC Editor: please remove this section before publication. CSOAI measurement capsule builder (Council of AI, contact nicholas@csoai.org): a prototype Python builder and verifier. Seven adapters each check the signature and pinned digests of an existing signed measurement record; one constructor enforces and the digest-only rule and refuses any capsule whose bytes differ from an independent RFC 8785 library's output. Licence Apache-2.0; source published at https://huggingface.co/datasets/csoai/evidence-index/tree/main/source (commit 10094094). Not implemented: COSE_Sign1, registration, effect_reference, blinded digests. As of 26 September 2026, each item checked against the live artefact that day: The index (schema csoai.measurement-capsule-index/0.2) binds 13,184 capsules of schema csoai.measurement-capsule/0.2 in 8 batches of 7 kinds, with index root 85533b833d36f8a4... (in full in the index). Capsule files, leaf lists and batch records are published under https://councilof.ai/measurement-capsules/v0.2/; the index, its signature and timestamp proof are also in the dataset huggingface.co/datasets/csoai/evidence-index (commit 8be939c5), as the genesis of a daily chain whose length that day was one. The index's OpenTimestamps proof carries a Bitcoin attestation at block 968674; the batch records' proofs were still calendar commitments. The signed payloads of the index and the chain head are in Rekor at log indexes 2968539665 and 2968539944. A browser verifier at https://councilof.ai/verify-server/ returns every capsule held about one endpoint and re-derives inclusion; the MCP tools measurement_index, verify_capsule (which returns a capsule's audit path) and server_evidence are served at https://councilof.ai/mcp/. A checker sharing no code with the builder, written by the same organisation, recomputed from the published files all 13,184 identifiers under its own JCS serialiser (every stored line matched byte for byte), all batch roots and the index root, and verified the index and chain-head signatures. It is not the independent implementation the experiment asks for. Capsules by kind, with the largest states: contract_parity 9,148 (CONSISTENT 5,570, INCONSISTENT 2,905, UNCHECKABLE 673; 5,814 distinct endpoints); tool_drift 3,240 (UNCHECKABLE 1,755, UNCHANGED_AT_NAME_GRANULARITY 1,485); cross_ledger_supply 353 (CONSISTENT 101, OPERATOR_API 77, UNCHECKABLE 52, STATE_PROOF_VERIFIED 49, INCONSISTENT 4, 70 in six other states); cross_runtime_reproduction 154 (NOT_REPRODUCED 89, REPRODUCED_ITEMWISE 54, REPRODUCED_AGGREGATE_ONLY 11); self_parity 138 (NOT_LISTED 55, CONSISTENT 37, UNCHECKABLE 37, INCONSISTENT 8, NOT_DECLARED 1); public_signal 118 (MEASURED 103, UNCHECKABLE 12, PARTIAL 3); a2a_card_signature 33 (VERIFIED 13, UNCHECKABLE 12, FAILED 8). 296 capsules are self-measurements: the 138 self-parity capsules (self by kind), 4 contract-parity capsules on the Issuer's own endpoint (flagged in claim) and the 154 cross-runtime capsules, which re-run the Issuer's own evaluation cards but carry no explicit flag. Of the 118 public-signal capsules, 50 concern the Issuer's own packages and 43 cannot separate its activity from others'. The other 12,770 concern subjects with which the Issuer has no stated relationship. 12 capsules carry a correction pointer; effect_reference is null in all. Capsules are 1,175 to 28,005 bytes (median 2,163). An earlier, unpublished 0.1 grammar used a non-RFC 9162 tree; its batches were rebuilt under this profile.

The Experiment The experiment asks whether an unaffiliated, authority-free declared-versus-observed record is useful alongside actor-issued receipts in a SCITT deployment. It is judged by four outcomes: (1) an implementation written by another party from this text recomputes the identifiers and roots of a published batch; (2) a batch is registered with a Transparency Service operated by another party and its Receipt is verified by a third; (3) a capsule carries an effect_reference to a Signed Statement from a different Issuer; (4) the open issues are resolved and published as corrections without loss of existing batches. If none occurs within two revisions, the author will withdraw the draft.

Open Issues (1) COSE_Sign1 encoding over a Sig_structure; (2) the superseded capsule_id in correction_pointer; (3) a per-kind allowlist of member names in place of the denylist; (4) neutral names for the csoai.-prefixed identifiers, and per-kind state vocabularies in a registry or appendix; (5) blinded digests for non-public sources; (6) whether observation-only kinds such as public_signal belong here; (7) an explicit self-measurement member, since kind and claim do not mark every case.

This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed:.plus,.cat, and.det for the construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and.feature for indicating the use of a non-basic feature in an instance. This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document defines new CBOR Object Signing and Encryption (COSE) header parameters for signaling a payload as an output of a hash function. This mechanism enables faster validation, as access to the original payload is not required for signature validation. Additionally, hints of the hashed payload's content format and availability are defined, providing references to optional discovery mechanisms that can help to find the original payload content. Fraunhofer SIT Bowball Technologies Ltd Microsoft Research This document specifies a REST API with the HTTP resources, request and response messages, and error handling needed for an interoperable implementation of a SCITT Transparency Service, as defined by the Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture. Action State Group, Inc. Tyche Institute Independently written systems that anchor records to a SCITT Transparency Service repeatedly need the same construction: a canonical form of structured content, a content-addressed identifier derived from that form, binding to a SCITT Signed Statement and Receipt, and references that cite external artifacts by digest. This document, referred to as CPB, specifies that construction as declarations rather than as a payload format. A payload profile declares its canonicalization algorithm and exclusion set and thereby obtains a reproducible derived identifier. A CPB Signed Statement carries either the complete statement content as specified by RFC 9943 or a digest of content held elsewhere using the COSE Hash Envelope of RFC 9995. CPB also defines an abstract typed digest reference information model and one optional protected-header encoding, cpb-refs; a payload profile may instead define its own reference serialization. An IANA registry assigns the canonicalization algorithm identifiers that these declarations name. CPB does not define payload content formats, establish or require a universal artifact-type registry, or require either typed-reference carrier. EMILIA Protocol, Inc. This document defines the EMILIA Protocol (EP) authorization receipt, an evidence artifact binding an enrolled approver key to one canonical action before execution. An approver-held key signs an Authorization Context containing the action hash, policy reference, shared authorization instance, per-signoff nonce, audience, and validity window. A Trust Receipt carries the signed contexts, terminal consumption record, and Merkle inclusion material so a relying party can verify the recorded event offline under independently selected log, directory, policy, and approver trust inputs. The receipt establishes only the guarantees of the selected verification profile. The mapping from an enrolled approver identifier to a natural person is asserted by the directory authority. Offline verification does not establish current revocation status, global non-replay, comprehension, legality, safety, or execution. Replay prevention requires an online atomic consumption store at the executor. The state-machine invariants are machine-checked under the assumptions stated in this document. This revision defines the closed EP-AUTHORIZATION-BUNDLE-v1 pre- execution profile and its verification algorithm. The bundle carries the Action Object, signed Authorization Contexts, signoffs, key proofs, and presentation evidence; it deliberately carries no terminal consumption or execution claim. An optional, profile- identified authorization binding can commit the human evidence to an independently verified native authorization artifact without replacing that artifact or making this receipt format depend on its transport or trust model. A receipt is evidence, not authorization. This document does not treat a local user interaction as an authorization decision. It defines one evidence artifact that an authorization architecture can use in a human-confirmation flow: the signed Authorization Context is action-bound confirmation evidence an authorization server MAY validate and bind to the grant it issues. The resulting Trust Receipt records terminal consumption and remains evidence; neither object makes the authorization decision. That decision remains with the authorization server. Asqav This document defines a profile for signed action receipts and independently checkable evidence about agent activity. It specifies versioned payload and signature semantics, hash-chain linkage, timestamp and witness policy, receipt verification and bounded regulatory-evidence mappings. It draws on ACTA-RECEIPTS but states its profile-specific overrides explicitly. A receipt supports checks about recorded bytes, identity, linkage and retained evidence; it does not by itself establish that an action occurred, that all actions were captured, or that an organization complies with a law. The profile supports retained historical receipts through explicit version and legacy rules rather than rewriting their committed bytes. Its intended core and implementation limitations are described in the body. kriya native This document specifies a format for action receipts: compact, individually signed JSON records that state that a specific AI agent attempted a specific action at a specific time, under a specific policy decision, and what the outcome was. Receipts are linked into an append-only hash chain so that deletion, insertion, reordering, or modification of any previously recorded receipt is detectable by a verifier that holds only the records and the signer's public key. The format is deliberately small and self-contained. Verification requires no network access, no service operated by the producer of the receipts, and no state beyond the records themselves and a trust anchor obtained out of band. This document specifies the record fields, the canonical byte sequence that is signed, the chain linkage rule, the verification procedure, and test vectors. NordenSoft This document profiles the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for AI-agent action receipts: tamper-evident, signed, offline-verifiable records of what an autonomous agent was recorded as doing at the governed boundary, under which recorded principal class, with what recorded verdict, and -- where the issuer records one -- under which policy identity. Each receipt is a signed record over a canonical JSON payload, hash- chained so that each record commits to its predecessor, and presented either bare -- the payload with its own native signature -- or enveloped in a COSE_Sign1. This revision specifies how such a receipt is carried as a SCITT Signed Statement, with the protected claims a Transparency Service requires, so that a receipt can be registered. Registration obtains a Transparency Service's signed proof that the statement was registered in its log -- a property a self-signed chain cannot provide alone. It does not, by itself, give an offline holder non-equivocation: that requires consistency proofs and monitoring of the log, which this profile does not specify. The profile makes a deliberately narrow, checkable claim: this is an issuer-authenticated, signature-verifiable, tamper-evident record of the action, the recorded principal class, the recorded verdict, and any policy identity the receipt carries. It explicitly does not claim that the agent was correct, safe, or wise, that the recorded inputs were true or complete, that a named approver authorized this exact action before it ran, that a downstream controller succeeded, or that any physical effect occurred. This revision separates those last three as distinct claims with independent failure behaviour, states the boundary of a shared action digest, and keeps a deterministic offline policy-replay capability out of scope. Council of AI (CSOAI Ltd) A signed statement conveyed as a COSE_Sign1 object may be serialized into many distinct byte sequences that all decode to the same data item. Where a protocol identifies such a statement by a digest computed over its wire octets (referred to here as a data-hash), the identifier is sensitive to that framing while the signature over the statement is not. This document reports a measurement of the size of that class. Taking one 165-octet COSE_Sign1 object and re-emitting it under every combination of six CBOR encoding freedoms yields 64 distinct octet sequences. All 64 carry an identical Sig_structure and therefore an identical, valid signature. All 64 produce distinct data-hash values, with no collisions. A stock CBOR decoder rejected none of them, and 31 were silently repaired into the canonical form by the act of being read. This document specifies nothing and proposes no wording. It reports a measurement, publishes the reproduction recipe, and identifies the prior work that already addresses the problem it measures. W3C Credentials Community Group OpenTimestamps Sigstore

Acknowledgments The drafts cited in the introduction sharpened the distinction this document draws. Any mischaracterisation of them is the author's.