Network Working Group Y.C. Chang Internet-Draft OIA Lab Intended status: Informational 16 April 2026 Expires: 18 October 2026 Delta-1: A SCITT Profile for Binary Settlement Receipts in Agentic AI Accountability draft-chang-delta1-settlement-00 Abstract This document defines Delta-1, a profile of the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture applied to AI agent decision accountability. Delta-1 specializes the SCITT receipt model for a specific use case: proving that an individual AI decision met three accountability conditions simultaneously: C1: Evidence of the decision process was consumed and sealed. C2: Strategic intent was isolated from inference providers. C3: An authorized party recorded the settlement. The verdict is binary (VALID or INVALID) with no intermediate states. Receipts are independently verifiable without the issuing infrastructure being online, subject to the trust and attestation assumptions defined in this document. By building on the SCITT framework, Delta-1 inherits transparency-log semantics, receipt conventions, and verification patterns, while extending them with domain-specific requirements for AI decision closure. This profile is intended for regulated industries, including finance, healthcare, and legal, operating under accountability and record- retention obligations. Note to RFC Editor This document is submitted as an individual Internet-Draft. Remove this note prior to publication as an RFC. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Chang Expires 18 October 2026 [Page 1] Internet-Draft Delta-1 Settlement Receipts April 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship to SCITT . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Receipt Structure . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Required Fields . . . . . . . . . . . . . . . . . . . . . 5 4.2. Optional Fields . . . . . . . . . . . . . . . . . . . . . 6 5. Condition Evaluation . . . . . . . . . . . . . . . . . . . . 6 5.1. C1: Evidence Consumed . . . . . . . . . . . . . . . . . . 6 5.2. C2: Intent Isolated . . . . . . . . . . . . . . . . . . . 7 5.3. C3: Settlement Recorded . . . . . . . . . . . . . . . . . 7 5.4. Binary Conjunction . . . . . . . . . . . . . . . . . . . 7 6. Transcript Binding . . . . . . . . . . . . . . . . . . . . . 8 6.1. Binding Fields . . . . . . . . . . . . . . . . . . . . . 8 7. Anti-Replay Protection . . . . . . . . . . . . . . . . . . . 9 7.1. Run ID Nonce . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Monotonic Sequence Number . . . . . . . . . . . . . . . . 9 8. Signature and Verification . . . . . . . . . . . . . . . . . 9 8.1. Proof Construction and Signing . . . . . . . . . . . . . 9 8.2. Verification . . . . . . . . . . . . . . . . . . . . . . 9 9. Hardware Attestation (Optional) . . . . . . . . . . . . . . . 10 9.1. Attestation Proof Structure . . . . . . . . . . . . . . . 10 9.2. Attestation Verification . . . . . . . . . . . . . . . . 10 Chang Expires 18 October 2026 [Page 2] Internet-Draft Delta-1 Settlement Receipts April 2026 9.3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 11 10. Receipt Lifecycle . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Immutability . . . . . . . . . . . . . . . . . . . . . . 11 10.2. Archival . . . . . . . . . . . . . . . . . . . . . . . . 11 10.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 11 11. Transport Considerations . . . . . . . . . . . . . . . . . . 11 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12.1. Self-Attestation Risk . . . . . . . . . . . . . . . . . 12 12.2. Key Management . . . . . . . . . . . . . . . . . . . . . 12 12.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 12 12.4. Transcript Transplantation . . . . . . . . . . . . . . . 12 12.5. Side-Channel Attacks on TEE . . . . . . . . . . . . . . 12 12.6. Timing Information . . . . . . . . . . . . . . . . . . . 12 12.7. JSON Canonicalization . . . . . . . . . . . . . . . . . 12 12.8. Key Rotation and Revocation . . . . . . . . . . . . . . 13 12.9. Validator Integrity . . . . . . . . . . . . . . . . . . 13 12.10. TEE Vendor Generalization . . . . . . . . . . . . . . . 13 12.11. Quote Freshness . . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13.1. Media Type Registration . . . . . . . . . . . . . . . . 13 14. Normative References . . . . . . . . . . . . . . . . . . . . 14 15. Informative References . . . . . . . . . . . . . . . . . . . 15 Appendix A. JSON Schema . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Example Receipts . . . . . . . . . . . . . . . . . . 17 VALID Receipt (All Conditions Met) . . . . . . . . . . . . . . 17 INVALID Receipt (C2 Failed) . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction As AI agents increasingly make or assist in consequential decisions, such as financial trades, clinical recommendations, procurement approvals, and legal assessments, organizations need a mechanism to prove that each decision met defined accountability conditions at the time it was made. Current approaches often provide authorization semantics ("this AI action was approved") but not settlement semantics ("the decision's accountability conditions can be cryptographically proven after the fact"). This gap creates regulatory, legal, and operational risk. 1.1. Relationship to SCITT The SCITT architecture defines a framework for creating transparent, tamper-evident signed statements registered on append-only transparency services, with receipts proving inclusion. Delta-1 maps SCITT concepts to AI decision accountability: Chang Expires 18 October 2026 [Page 3] Internet-Draft Delta-1 Settlement Receipts April 2026 * SCITT Signed Statement = Delta-1 condition evaluation result * SCITT Transparency Service = append-only evidence chain * SCITT Receipt = Delta-1 settlement receipt (binary verdict) * SCITT Issuer = AI decision pipeline being attested * SCITT Verifier = Customer, auditor, or regulator Delta-1 extends SCITT with: * Binary verdict semantics (VALID or INVALID, with no scoring) * Three-condition conjunction (C1 AND C2 AND C3) * Transcript binding to prevent receipt transplantation * Anti-replay protection via run identifiers and monotonic counters * Optional hardware attestation to upgrade trust from software self- report to hardware-attested execution 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology Settlement Receipt A cryptographically signed document attesting to the binary verdict of a Delta-1 evaluation. Delta-1 (D1) The conjunction of three conditions (C1 AND C2 AND C3) that, when all are true, indicates accountability closure for a single AI decision. C1 (Evidence Consumed) The decision's evidence chain has been recorded in an append-only, tamper-evident store and sealed. C2 (Intent Isolated) Strategic intent was fragmented or transformed before reaching the inference provider, preventing the provider from reconstructing the decision-maker's strategy under the threat model defined by the deployment. C3 (Settlement Recorded) An authorized party has reviewed and signed off on the decision's closure. Chang Expires 18 October 2026 [Page 4] Internet-Draft Delta-1 Settlement Receipts April 2026 BBOX Black-box evidence chain: an append-only, hash-linked log of decision-process steps. Transcript Binding A canonical digest that cryptographically binds the receipt to the pipeline execution context. 3. Protocol Overview The Delta-1 protocol operates as the final step in an AI decision accountability pipeline: 1. AI query is processed through privacy and isolation layers. 2. Evidence of each processing step is recorded in the evidence chain. 3. The evidence chain is sealed. 4. The Delta-1 validator evaluates C1, C2, and C3. 5. A binary receipt is produced: VALID or INVALID. 6. The receipt is signed using the customer's signing key. 7. Optional hardware attestation evidence is attached. 8. The receipt is delivered for archival and later verification. Verification is performed by the receipt holder. Offline verification of the receipt signature and transcript binding is REQUIRED. Verification of optional external artifacts, such as TEE quote status or trusted time evidence, MAY depend on cached trust anchors or online validation services, depending on local policy. 4. Receipt Structure A Delta-1 receipt is a JSON object with the following fields. 4.1. Required Fields schema_version String. MUST be "delta1-v1". receipt_id String. Globally unique identifier for this receipt. RECOMMENDED format: "EP-" followed by 8 or more hexadecimal characters. session_id String. Identifier of the decision session. Chang Expires 18 October 2026 [Page 5] Internet-Draft Delta-1 Settlement Receipts April 2026 run_id String. Globally unique nonce for anti-replay protection. MUST NOT be reused across receipts. sequence_number Unsigned integer. Monotonically increasing counter per issuing validator instance. delta1_valid Boolean. True if and only if C1, C2, and C3 are all true. conditions_met Object containing boolean fields c1, c2, and c3. timestamp String. RFC 3339 timestamp of receipt issuance. proof_hash String. SHA-256 digest of the canonical proof input defined in Section 8.1. signature String. Ed25519 signature over the proof_hash, produced by the customer's signing key. public_key_ref String. Reference to the public key used for signature verification. 4.2. Optional Fields transcript_digest String. Canonical digest of the pipeline execution context. REQUIRED for production deployments. attestation Object. Hardware attestation proof, if a TEE is used. bbox_seal_hash String. SHA-256 digest of the sealed evidence chain. trusted_time Object. Optional trusted time evidence, such as RFC 3161 or Roughtime-derived proof. 5. Condition Evaluation The Delta-1 validator MUST evaluate three conditions. All three MUST be true for the receipt to be VALID. 5.1. C1: Evidence Consumed C1 is true when all of the following hold: a. An evidence chain exists for the session. b. The chain contains at least the minimum required evidence packets; implementation-defined, RECOMMENDED value is 3 or greater. Chang Expires 18 October 2026 [Page 6] Internet-Draft Delta-1 Settlement Receipts April 2026 c. Required processing layers are represented in the chain. d. Chain integrity is valid and hash linkage is unbroken. e. The chain has been sealed and no further entries are accepted. 5.2. C2: Intent Isolated C2 is true when all of the following hold: a. Intent fragmentation or transformation was applied before transmission to the inference provider. b. Training-signal blocking mechanisms were active. c. Confirmation-denial or equivalent response screening verified that provider responses did not reveal protected original entities. d. Under the deployment threat model, the original intent is not reconstructable from the transformed query material delivered to providers. Deployments claiming C2 compliance SHOULD document the threat model, attacker vantage point, and reconstruction criteria used for validation. 5.3. C3: Settlement Recorded C3 is true when all of the following hold: a. A settlement record exists for the session. b. The settlement was produced by an authorized signer. c. The signature is cryptographically valid. d. The settlement has not expired. e. Closure was explicitly acknowledged and was not purely automatic. 5.4. Binary Conjunction The verdict is computed as follows: delta1_valid = c1 AND c2 AND c3 Chang Expires 18 October 2026 [Page 7] Internet-Draft Delta-1 Settlement Receipts April 2026 There is no partial validity, no scoring, and no weighted average. Two out of three conditions being true still yields INVALID. 6. Transcript Binding To prevent receipt transplantation, the receipt SHOULD include a transcript binding digest. The transcript_digest is computed as follows: transcript_digest = SHA-256( original_request_digest || transformed_request_digests || provider_dispatch_map || provider_response_digests || trt_verdict_digest || bbox_seal_hash || policy_versions || model_identities ) 6.1. Binding Fields original_request_digest SHA-256 of the user's original query before transformation. transformed_request_digests SHA-256 of each transformed fragment sent to providers. provider_dispatch_map Ordered pairs of fragment identifier and provider identifier. provider_response_digests SHA-256 of each provider's raw response. trt_verdict_digest SHA-256 digest of the transformation or sanitization verdict. bbox_seal_hash SHA-256 digest of the sealed evidence chain. policy_versions Identifiers of active policy versions at processing time. model_identities Provider and model identifiers used in the pipeline. Chang Expires 18 October 2026 [Page 8] Internet-Draft Delta-1 Settlement Receipts April 2026 7. Anti-Replay Protection 7.1. Run ID Nonce Each receipt MUST contain a globally unique run_id. The validator MUST reject any validation request whose run_id has been previously used. Implementations SHOULD use cryptographically random identifiers of at least 128 bits. 7.2. Monotonic Sequence Number Each receipt MUST contain a sequence_number that is strictly greater than the sequence_number of any previous receipt from the same validator instance. Gaps are permitted, such as after rejected validations, but decreases are not permitted. 8. Signature and Verification 8.1. Proof Construction and Signing Before computing proof_hash, implementations MUST construct a canonical proof input object containing the following fields: session_id, run_id, sequence_number, conditions_met, transcript_digest, and timestamp. The proof input object MUST be serialized using the JSON Canonicalization Scheme (JCS) defined in [RFC8785]. The proof_hash is the SHA-256 digest of that canonicalized byte string. The receipt signature MUST use Ed25519 [RFC8032]. The signed payload is the proof_hash. The signing key MUST be controlled by the customer, not by the infrastructure vendor. 8.2. Verification Verification requires, at minimum: a. The receipt JSON document. b. The customer's Ed25519 public key. Verification procedure: Chang Expires 18 October 2026 [Page 9] Internet-Draft Delta-1 Settlement Receipts April 2026 1. Recompute proof_hash from the canonical proof input. 2. Verify the Ed25519 signature against proof_hash. 3. If transcript_digest is present, verify that it matches the expected canonical digest. 4. If sequence tracking is implemented, verify that sequence_number exceeds the last known value for the validator instance. Verification of receipt signature and transcript binding MUST NOT require network access, vendor APIs, or online services. 9. Hardware Attestation (Optional) When the Delta-1 validator executes inside a Trusted Execution Environment (TEE), the receipt MAY include attestation evidence. 9.1. Attestation Proof Structure tee_type TEE technology identifier, such as sgx_dcap, sev_snp, cca, or nitro. quote The TEE attestation artifact appropriate to tee_type. measurement Measurement of the trusted execution payload, such as MRENCLAVE or equivalent. signer_identity Identity of the signing authority for the measured payload, if applicable. tcb_level Status of the TEE trusted computing base. report_data_hash The receipt proof_hash bound into the attestation evidence. mode Deployment mode. Simulation values MUST NOT be trusted in production. 9.2. Attestation Verification Attestation verification depends on tee_type and local trust policy. Implementations MAY validate attestation online, or offline using cached collateral and trust anchors. At minimum, verifiers SHOULD: Chang Expires 18 October 2026 [Page 10] Internet-Draft Delta-1 Settlement Receipts April 2026 A. Verify the attestation evidence against the relevant TEE trust chain. B. Verify that the measured payload matches an expected published measurement. C. Verify that report_data_hash equals receipt.proof_hash. D. Verify that tcb_level is acceptable under local policy. 9.3. Trust Model Without attestation, the customer trusts that vendor-operated software ran correctly. With attestation, trust shifts toward the TEE platform and its measurement chain. This is a substantial trust upgrade, but not a zero-trust guarantee. 10. Receipt Lifecycle 10.1. Immutability A receipt, once issued, MUST NOT be modified. If a condition is later found to have been recorded incorrectly, a new receipt MUST be issued with a new receipt_id and the updated verdict. 10.2. Archival Receipts SHOULD be archived by the customer for the duration required by applicable regulation, contract, or internal retention policy. 10.3. Chain of Custody To prove accountability over a period of time, implementations MAY chain receipts by incorporating the previous receipt's proof_hash into the next receipt's transcript binding. 11. Transport Considerations Delta-1 receipts are transport-agnostic. They MAY be delivered via: * HTTPS API response for real-time systems * File download, including compliance or legal export flows * Message queue for asynchronous processing pipelines * Blockchain anchoring for optional public verifiability Chang Expires 18 October 2026 [Page 11] Internet-Draft Delta-1 Settlement Receipts April 2026 The receipt format is JSON. Implementations SHOULD support both JSON and CBOR [RFC8949] encodings where bandwidth-constrained environments require compact encoding. 12. Security Considerations 12.1. Self-Attestation Risk Without TEE support, the receipt is ultimately a software self- report. A compromised validator can produce fraudulent VALID receipts. 12.2. Key Management The customer's Ed25519 signing key is a root of trust. Compromise of this key permits forged receipts. Implementations SHOULD use hardware security modules or equivalent protections. 12.3. Replay Attacks run_id nonces and monotonic sequence_number values are used to mitigate replay attacks. Validators MUST reject duplicate run_id values. 12.4. Transcript Transplantation Without transcript binding, a valid receipt could be attached to a different decision. Production deployments SHOULD include transcript binding. 12.5. Side-Channel Attacks on TEE TEE technologies remain exposed to side-channel and implementation- level attacks. Current mitigations reduce, but do not eliminate, residual risk. 12.6. Timing Information The timestamp in the receipt is produced by the validator's local clock. High-assurance deployments SHOULD bind receipt issuance time to a trusted external time source, such as RFC 3161 or Roughtime- based evidence. 12.7. JSON Canonicalization Receipt proof construction MUST use JCS canonicalization before hashing. Without deterministic serialization, semantically identical content can yield different proof_hash values. Chang Expires 18 October 2026 [Page 12] Internet-Draft Delta-1 Settlement Receipts April 2026 12.8. Key Rotation and Revocation Implementations MUST support key rotation. Historical receipts signed by an old key remain valid if the corresponding public key and validity period are preserved. 12.9. Validator Integrity The Delta-1 validator is a single point of trust when no TEE is used. Reproducible builds, transparency logs, and multi-party validation are RECOMMENDED mitigations for high-assurance deployments. 12.10. TEE Vendor Generalization Implementations SHOULD support multiple TEE families and MUST distinguish them using tee_type. 12.11. Quote Freshness Attestation artifacts can be replayed. Binding proof_hash into report_data_hash ensures that an attestation artifact covers exactly one receipt instance. 13. IANA Considerations This document requests registration of the "application/ delta1-receipt+json" media type in the "Media Types" registry. 13.1. Media Type Registration Type name application Subtype name delta1-receipt+json Required parameters None. Optional parameters version, default value "delta1-v1". Encoding considerations Binary. Delta-1 receipt documents are UTF-8 encoded JSON texts. Security considerations See Section 12. Interoperability considerations Interoperability depends on consistent canonicalization, proof construction, and algorithm support as defined in this specification. Published specification This document. Chang Expires 18 October 2026 [Page 13] Internet-Draft Delta-1 Settlement Receipts April 2026 Applications that use this media type AI accountability systems, evidence archival systems, regulatory reporting systems, and audit verification tools. Fragment identifier considerations Same as for application/json. Additional information Magic number: N/A. File extension: .delta1.json. Macintosh file type code: N/A. Person and email address to contact for further information YC Chang, yc@oia-lab.com Intended usage Common. Restrictions on usage None. Author YC Chang Change controller IETF 14. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Chang Expires 18 October 2026 [Page 14] Internet-Draft Delta-1 Settlement Receipts April 2026 [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [SCITT-ARCH] Birkholz, H., "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture, . 15. Informative References [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, . [P11] Chang, Y., "Authorization Is Not Settlement: Why AI Accountability Requires Binary Closure", DOI 10.5281/zenodo.19338864, March 2026, . [EUAIA] Council, E. P. A., "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act)", 2024. [COAIA] Colorado, S. O., "SB 24-205 Concerning Consumer Protections for Artificial Intelligence", 2024. [FORESHADOW] Bulck, J. V., "Foreshadow: Extracting the Keys to the Intel SGX Kingdom", 2018. Appendix A. JSON Schema Chang Expires 18 October 2026 [Page 15] Internet-Draft Delta-1 Settlement Receipts April 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "Delta1Receipt", "type": "object", "required": [ "schema_version", "receipt_id", "session_id", "run_id", "sequence_number", "delta1_valid", "conditions_met", "timestamp", "proof_hash", "signature", "public_key_ref" ], "properties": { "schema_version": { "type": "string", "const": "delta1-v1" }, "receipt_id": { "type": "string" }, "session_id": { "type": "string" }, "run_id": { "type": "string" }, "sequence_number": { "type": "integer", "minimum": 1 }, "delta1_valid": { "type": "boolean" }, "conditions_met": { "type": "object", "required": ["c1", "c2", "c3"], "properties": { "c1": { "type": "boolean" }, "c2": { "type": "boolean" }, "c3": { "type": "boolean" } } }, "timestamp": { "type": "string", "format": "date-time" }, "proof_hash": { "type": "string" }, "signature": { "type": "string" }, "public_key_ref": { "type": "string" }, "transcript_digest": { "type": "string" }, "bbox_seal_hash": { "type": "string" }, Chang Expires 18 October 2026 [Page 16] Internet-Draft Delta-1 Settlement Receipts April 2026 "trusted_time": { "type": "object", "properties": { "type": { "type": "string" }, "value": { "type": "string" } } }, "attestation": { "type": "object", "properties": { "tee_type": { "type": "string" }, "quote": { "type": "string" }, "measurement": { "type": "string" }, "signer_identity": { "type": "string" }, "tcb_level": { "type": "string" }, "report_data_hash": { "type": "string" }, "mode": { "type": "string" } } } } } Appendix B. Example Receipts VALID Receipt (All Conditions Met) Chang Expires 18 October 2026 [Page 17] Internet-Draft Delta-1 Settlement Receipts April 2026 { "schema_version": "delta1-v1", "receipt_id": "EP-mnu2gmo2-df9ba6d5", "session_id": "session-20260414-e3f1", "run_id": "run-20260414-a7f3b2c1d4e5", "sequence_number": 42, "delta1_valid": true, "conditions_met": { "c1": true, "c2": true, "c3": true }, "timestamp": "2026-04-14T10:24:15Z", "proof_hash": "3fa2b7c1e8d9f4a5b6c7d8e9f0a1b2c3...", "signature": "ed25519:MIGHAoGBANr5nD1y4X...", "public_key_ref": "customer_hsm_key_001", "transcript_digest": "a1b2c3d4e5f6a7b8c9d0e1f2...", "bbox_seal_hash": "9a8b7c6d5e4f3a2b1c...", "attestation": { "tee_type": "sgx_dcap", "quote": "SIMULATION:abc123...", "measurement": "f7a2b1c3d4e5f6a7b8c9d0e1...", "signer_identity": "e1f2a3b4c5d6e7f8a9b0c1d2...", "tcb_level": "simulation", "report_data_hash": "3fa2b7c1e8d9f4a5b6c7d8e9f0a1b2c3...", "mode": "simulation" } } INVALID Receipt (C2 Failed) { "schema_version": "delta1-v1", "receipt_id": "EP-x9k3m7p2-c4a1b8f3", "session_id": "session-20260414-b2c3", "run_id": "run-20260414-f8e7d6c5b4a3", "sequence_number": 43, "delta1_valid": false, "conditions_met": { "c1": true, "c2": false, "c3": true }, "timestamp": "2026-04-14T10:25:02Z", "proof_hash": "7b8c9d0e1f2a3b4c5d6e7f8a...", "signature": "ed25519:KJHFaskjdfh...", "public_key_ref": "customer_hsm_key_001", "transcript_digest": "" } Author's Address YC Chang OIA Lab Email: yc@oia-lab.com URI: https://oia-lab.com Chang Expires 18 October 2026 [Page 18]