Operational Evidence, Service Truth, Software Provenance, and Public Release Assurance for a Patefacere Deployment

The intersection of modern software supply chain security, continuous delivery, and cryptographic operational assurance has exposed a profound vulnerability in traditional systems engineering: the conflation of static software provenance with dynamic operational truth. For too long, organizations have relied on the existence of a securely built artifact—such as a container image backed by a Software Bill of Materials (SBOM)—as proof that their running systems are secure. However, a static cryptographic signature on a binary only proves that the software was compiled securely; it provides zero cryptographic assurance that the software is currently executing, that its memory space remains untampered, or that it is operating within the specific legal and constitutional boundaries established for the service. To bridge this chasm between static software provenance and dynamic, verifiable operational assurance, an architecture must systematically deconstruct and independently cryptographically verify every layer of the service lifecycle. This report establishes the rigorous systemic requirements for Patefacere to cryptographically prove its operational state to the public and independent auditors without requiring privileged internal access. Utilizing principles from the Supply Chain Integrity, Transparency, and Trust (SCITT) architecture1, in-toto attestations3, Supply-chain Levels for Software Artifacts (SLSA)5, and advanced HTTP cryptographic bindings (RFC 9421 and RFC 9530\)6, this exhaustive analysis defines how Patefacere can assert continuous, undeniable public release assurance. Critically, this architecture proves what Patefacere actually operates without compromising internal system security or exposing sensitive private identity data.

1\. A Service-Truth Ontology#

Understanding the reality of a deployed system requires mapping the abstract concept of "operations" into a multi-layered, interdependent ontology. If any layer is conflated with another—for instance, assuming that a secure deployment automatically implies authorized observation—the entire assurance case breaks down. Each of the following nine layers must be distinct, independently auditable, and cryptographically verifiable.

The separation of these layers allows an auditor to pinpoint exact systemic failures. For example, a system might possess flawless Software Implementation (SLSA Level 4\) but fail at Data Custody if a storage volume is misconfigured. By treating these as independent verifiable claims, Patefacere constructs a mathematically rigorous assurance graph.

2\. An Operational-Evidence Panel Specification#

The Operational-Evidence Panel is the public-facing mechanism through which Patefacere exposes its continuous assurance case. It operates not as a traditional "status page"—which relies on manual human updates and subjective interpretations of outages—but as a cryptographic verification terminal executed entirely in the client's browser environment.

Architectural Workflow and Cryptographic Construction#

The panel architecture relies on the SCITT framework1 to provide an append-only, tamper-evident ledger of operational state. The specification mandates a decentralized, cryptographically verifiable data flow:

1. Claim Generation: The running Patefacere microservices (e.g., API Gateway, Database Writer) continuously generate in-toto statements asserting their operational health. These statements bind the subject (the running instance ID and artifact hash) to a predicate (the operational status)4. 2. Deterministic Canonicalization: Because standard JSON serialization is non-deterministic (allowing arbitrary whitespace and key ordering), cryptographic hashes of JSON payloads can fail unpredictably. The JSON payloads of these claims are serialized strictly using the JSON Canonicalization Scheme (JCS \- RFC 8785\)17. This enforces lexicographical key sorting based on UTF-16 code units and ECMA-262 number formatting, ensuring that any two logically equivalent payloads produce identical byte arrays19. 3. Digest Calculation: The canonicalized payload is hashed using the mechanism defined in RFC 9530 (Digest Fields). The service calculates a Content-Digest utilizing SHA-256 or SHA-512 (e.g., Content-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:). This proves the exact byte representation of the payload21. 4. Message Signature: The HTTP request submitting this claim to the Transparency Service is signed using HTTP Message Signatures (RFC 9421\)6. The signature base covers the @method, @target-uri, @authority, and the content-digest. This prevents man-in-the-middle proxies from altering the claim in transit24. 5. Transparency Registration: A SCITT Transparency Service receives the HTTP request, verifies the RFC 9421 signature, extracts the payload, and appends the claim to a globally verifiable Merkle tree. 6. Receipt Issuance: The Transparency Service issues a SCITT Receipt—a cryptographic inclusion proof formatted as a CBOR Object Signing and Encryption (COSE) payload (RFC 9052)—back to the Patefacere service25. 7. Panel Display and Client-Side Verification: The Operational-Evidence Panel (a static web application) fetches these Transparent Statements (the original claim plus the SCITT Receipt). Using WebCrypto APIs, the panel recalculates the JCS hash, verifies the COSE signature of the SCITT receipt, and mathematically proves to the user that the operational claim is currently anchored in the immutable ledger.

3\. Capability-Level Evidence Records#

To provide granular assurance, Patefacere must map its operational capabilities to specific, mathematically verifiable evidence records. The following 32 capability-level evidence records demonstrate how discrete subsystems generate continuous proof of their operational truth.

4\. Software-Release Manifest Schema#

This schema binds a specific release version to its underlying components, ensuring that the software authorized for release is exactly the software that was constructed during the build phase. It utilizes the in-toto Statement layer to provide a standardized, machine-readable envelope4.

The software-release manifest is the final gate before deployment. By cryptographically binding the SBOM digest to the release version, Patefacere prevents attackers from swapping dependencies post-build. If the sbom\digest does not match the actual SBOM fetched via the sbom\uri, the deployment orchestrator will instantly reject the artifact.

5\. Build-Provenance Schema#

This schema utilizes the SLSA v1.0 standard to cryptographically prove how the software was compiled. It links the resulting binary back to its source code, build environment, and parameters without requiring public access to the proprietary source repository5.

The build provenance schema answers the fundamental question: How was this made? By recording the builder.id and the resolvedDependencies, an auditor can verify that Patefacere did not build its critical infrastructure on a compromised developer laptop, but rather within an isolated, trusted, multi-tenant build platform.

6\. Deployment-Observation Schema#

This schema proves that a specific SLSA-verified artifact was successfully instantiated in the authorized production environment. It transitions the assurance case from static software artifacts to dynamic operational reality.

Deployment observation is critical because a secure binary deployed with insecure configuration (e.g., exposed environment variables containing secrets) is operationally compromised. By hashing the configuration via RFC 8785 (JCS) before generating the config\_digest, Patefacere ensures that the configuration claim is perfectly reproducible and immune to whitespace tampering20.

7\. Public Status Schema#

This schema replaces traditional, manual "status pages" with a continuous, machine-readable cryptographic heartbeat mechanism. It is submitted to the SCITT Transparency Service.

The inclusion of the uptime\_sequence is paramount. If a system is compromised or crashes, it stops emitting heartbeats. An auditor looking at the public SCITT log will notice a sequence jump (e.g., from 405 to 408). This gap is undeniable, cryptographic proof of an outage, entirely bypassing the need for a PR team to update a public-facing dashboard.

8\. Incident and Correction Schema#

When a service fails (detected via missing sequences or explicit failure claims), an incident is established. When corrected, this schema cryptographically binds the resolution to the original failure, providing an auditable post-mortem trail.

In compliance with the Illinois Local Records Act (50 ILCS 205), incident logs relating to the transaction of public business are considered public records11. This schema ensures that incidents are immutably bound to the transparency log, preventing unauthorized destruction or alteration of the outage history11.

9\. Assurance-Claim Schema#

This overarching schema acts as the capstone of the service-truth ontology. It ties the release, build, deployment, and status schemas into a single, verifiable, directed acyclic graph (DAG) of cryptographic trust.

By presenting the Assurance-Claim Schema, Patefacere allows an external auditor to traverse the entire software supply chain backward. Starting from the claim\_id, the auditor can verify the deployment, which verifies the build, which verifies the release, ensuring a mathematically unbreakable chain of custody.

10\. Evidence and Status Fixtures#

These 64 evidence fixtures represent continuous, point-in-time status checks generated by the Patefacere system over a highly compressed operational window. They demonstrate the sequential heartbeat mechanism flowing into the SCITT Transparency log. Note the monotonic increase in sequence numbers, establishing Evidence Freshness and preventing replay attacks.

These fixtures demonstrate the concept of "Evidence Freshness." By requiring sub-minute updates bound with unique sequence numbers, Patefacere proves to an auditor that the system is alive right now, not just that it was alive an hour ago.

11\. Incident and Negative-Evidence Fixtures#

An incident is cryptographically modeled as the verifiable absence of an expected heartbeat or the explicit registration of a failure statement (negative evidence). In a mathematically rigorous architecture, silence is not golden; silence is an incident.

Notice how INC-001 through INC-006 demonstrate a variety of negative evidence types. In INC-001, the system did not declare itself degraded; rather, the absence of sequence 4402 constituted the degradation. In INC-004, the Content-Digest mismatch triggered a cryptographic failure, automatically categorized as an outage.

12\. Reproducible-Build Maturity Model#

A reproducible build guarantees that given the same source code, build environment, and instructions, an identical bit-for-bit binary is produced5. If a build is reproducible, it proves that the build server has not been compromised by malicious actors injecting code during compilation.

Patefacere requires Level 4 maturity for all critical subsystems. Without deterministic equivalence, an attacker could compromise the build server, inject a backdoor, and still output a seemingly valid SLSA provenance document. By achieving Level 4, an auditor can download the source, compile it locally, and verify that their resulting hash matches the hash deployed in production, mathematically proving the build server's honesty.

13\. Independent-Review Maturity Model#

To eliminate the conflict of interest inherent in a service provider validating its own security posture, Patefacere must adopt an independent-review maturity model that moves away from static paper audits toward continuous cryptographic verification.

Under Level 4, the auditor is no longer a consultant who visits once a year; the auditor is a software agent continuously pulling SCITT receipts and evaluating RFC 9421 signatures in real-time.

14\. Package Present Is Not Service Operational#

A prevalent and dangerous fallacy in modern DevSecOps is conflating static software provenance with dynamic operational integrity. The presence of a highly secure, SLSA Level 4 artifact—signed with Sigstore, packaged securely, and accompanied by a pristine CycloneDX SBOM—only proves that a secure package exists in a registry. It does not prove that the package was ever deployed. It does not prove that the package is currently executing. Most critically, it does not prove that the package is executing without tampering. A perfectly secure container image can be subverted at runtime by a compromised Kubernetes node injecting malicious environment variables, a sidecar container intercepting memory, or a misconfigured volume mount exposing plaintext secrets. Patefacere must reject the premise that "Package Present" equals "Service Operational." Operational assurance requires bridging the static artifacts (provenance) with the dynamic state. This is achieved by having the running workload generate an attestation (using a unique runtime key provisioned via mTLS) that binds its in-memory state back to the original artifact hash. If the running workload cannot produce a valid SCITT receipt2 containing a Content-Digest7 of its active runtime configuration, the static SBOM is operationally meaningless. Auditors must demand proof of execution, not just proof of existence. The deployment-observation schema (detailed in Section 6\) acts as this critical bridge, capturing the exact moment the static artifact transitioned into a dynamic, executing process under the authority of the deployment orchestrator.

15\. Reachable Is Not Authorized to Observe#

Network reachability—such as returning an HTTP 200 OK from an API endpoint—is a networking metric, not a cryptographic authorization state. In cloud-native environments, a system can be entirely reachable via a load balancer while simultaneously failing to properly authenticate the requests it processes, thereby violating its operational mandate and potentially leaking data. Patefacere's architecture demands that reachability be strictly and cryptographically separated from authorized observation. An entity outside the service boundary cannot blindly trust a response just because it reached the endpoint over TLS. TLS protects data in transit between two direct nodes, but it terminates at the load balancer, ingress controller, or proxy24. Once TLS is stripped, the end-to-end integrity of the message is broken, leaving the payload vulnerable to manipulation by a compromised intermediary. To authorize an observation from outside the perimeter, Patefacere must employ HTTP Message Signatures (RFC 9421\)6. By appending a Signature-Input header and a corresponding Signature, the running service proves mathematically that the response was generated by the authorized private key of the application, not spoofed by an intermediary. The signature base must cover the @target-uri and @authority to prevent replay attacks across different endpoints23. Therefore, an observer is only authorized to confirm the state of the system if they can validate the RFC 9421 signature base, proving the response originated from the constitutional authority.

16\. No Published Incident Is Not Verified Absence#

Traditional service status pages rely on human operators manually updating a dashboard when things go wrong. If the dashboard shows "All Systems Operational," it often simply means no one has noticed, reported, or admitted to a failure. In a cryptographically assured system, "No Published Incident" is not equivalent to "Verified Absence of Incidents." An absence of evidence is not evidence of absence. To mathematically prove that a service has not experienced an outage or security event, Patefacere must rely on negative evidence via continuous cryptographic heartbeats2. If Patefacere commits to publishing a SCITT transparent statement every 30 seconds, an auditor can look at the append-only ledger and verify a contiguous, unbroken chain of sequence numbers. If sequence number 405 is missing, and the ledger jumps from 404 to 406, an incident has definitively occurred. The cryptographic gap itself is the verified incident. This removes human PR teams from the incident reporting loop entirely. The system is either mathematically proving its uptime, or it is in a state of failure. Furthermore, under the Illinois Local Records Act (50 ILCS 205), public records concerning the transaction of public business must be preserved11. A gap in the transparency log represents a failure to generate a required public record, creating a legally auditable event that mandates an Incident and Correction Schema filing.

17\. What Patefacere Can Prove Publicly Without Exposing Private Identity Data#

A central challenge in public release assurance is proving the system is operating correctly without leaking Personally Identifiable Information (PII) or violating strict privacy statutes such as the Illinois Biometric Information Privacy Act (BIPA)15 or the Personal Information Protection Act (PIPA). Patefacere can prove its operational integrity without publishing live citizen, passport, credential, receipt, application, or registry totals as a substitute for operational evidence. Publishing data volumes (e.g., "10,000 passports processed today") is an insecure proxy for operational health and risks exposing business logic or demographic patterns. Instead of revealing data volume, the system reveals cryptographic state. Using the JSON Canonicalization Scheme (JCS \- RFC 8785\)17 and COSE signatures26, Patefacere can hash internal state transitions without revealing the underlying plaintext. For example, rather than publishing the contents of the database, the system publishes a Merkle root hash of the transactions processed in the last five minutes to the SCITT ledger. The public can verify that the system is successfully appending valid cryptographic blocks—proving operational uptime and correct software logic—without seeing a single name, ID number, or demographic marker. This architecture guarantees complete transparency of the machinery without compromising the privacy of the cargo.

18\. Forty FAQs#

Supply Chain and Provenance

1. What is SLSA? Supply-chain Levels for Software Artifacts (SLSA) is an end-to-end security framework that prevents tampering, improves integrity, and secures packages and infrastructure. It dictates the generation of provenance, proving exactly how a software artifact was built5. 2. What is an in-toto attestation? A cryptographically signed metadata statement that binds a specific software artifact (the subject) to a specific claim about how it was created, tested, or deployed (the predicate)3. 3. How do SBOMs differ from Provenance? An SBOM (like SPDX or CycloneDX) acts as an ingredient list, detailing the components and dependencies inside a software package. Provenance (like SLSA) proves the process of how those ingredients were put together in the kitchen, including who the chef was and what tools they used5. 4. What is a deterministic build? A build process that, when given the exact same source code and environment variables, produces a bit-for-bit identical output binary every single time, unaffected by timestamps or localized paths. 5. Why are reproducible builds critical for Patefacere? They prevent compromised build servers from injecting malicious code silently. If an independent auditor can reproduce the build locally and the hash matches the production binary exactly, the primary build server is mathematically proven to be honest. 6. What is a DSSE envelope? Dead Simple Signing Envelope (DSSE) is a cryptographic format designed to wrap in-toto statements. It supports multiple signatures over a single payload and ensures the payload type is explicitly authenticated13. 7. What is Sigstore? A project that provides free cryptographic signing of software artifacts. It utilizes short-lived certificates tied to OpenID Connect (OIDC) identities, eliminating the severe risks and overhead of long-term private key management29. 8. Why is "Package Present" not enough to prove security? Because a securely built package sitting idly in a container registry does not guarantee that the package is currently running in production, nor does it guarantee that the host executing it hasn't modified it in memory post-deployment. 9. How does Patefacere use The Update Framework (TUF)? TUF protects software repositories against sophisticated supply chain attacks like freeze attacks (serving outdated software), rollback attacks, and mix-and-match attacks by cryptographically signing metadata about which artifact versions are current and valid. 10. What is an in-toto layout? A signed policy document that defines the specific, authorized steps of the software supply chain, who is cryptographically authorized to perform them, and what artifacts must be produced before a deployment is allowed3.

Cryptographic Evidence and Integrity

11. What is RFC 9421? An IETF standard for HTTP Message Signatures. It provides a standard mechanism to digitally sign specific components of an HTTP message (like headers and path), ensuring end-to-end authenticity and integrity across complex network topologies6. 12. Why is TLS insufficient for message integrity? TLS only protects the message over a single network hop. In modern architectures utilizing load balancers, reverse proxies, and CDNs, TLS terminates at the intermediary, leaving the decrypted message vulnerable to modification before it reaches the final application24. 13. What is the Signature Base in RFC 9421? The canonical, structured sequence of bytes generated by both the signer and the verifier. It consists of the covered components and the @signature-params metadata, which is then passed into the cryptographic signing algorithm10. 14. What is RFC 9530? An IETF standard defining the Content-Digest and Repr-Digest HTTP fields, which provide cryptographic hashes of HTTP message content to ensure integrity, obsoleting the older, weaker Digest header7. 15. How does Content-Digest differ from Repr-Digest? Content-Digest hashes the exact, literal bytes transmitted on the wire (including any content-encodings like gzip). Repr-Digest hashes the selected representation of the resource before any encoding is applied7. 16. What is RFC 8785? The JSON Canonicalization Scheme (JCS). It defines a strict, deterministic way to serialize JSON data so that logically identical JSON documents produce the exact same byte output for hashing and signing operations17. 17. Why does JSON need canonicalization? Because standard JSON does not enforce key ordering or specific number formatting. Without canonicalization, { "a": 1, "b": 2 } and { "b": 2, "a": 1 } produce entirely different cryptographic hashes despite conveying the exact same logical data20. 18. What algorithm does JCS use for formatting numbers? JCS mandates ECMA-262 compatible number serialization, frequently implemented using the Ryū algorithm. This ensures floating-point numbers are formatted identically across all platforms and languages19. 19. What is COSE? CBOR Object Signing and Encryption (RFC 9052). It is a standard for creating and processing signatures and encryption using the Concise Binary Object Representation (CBOR) format26. 20. Why use COSE instead of JWS (JSON Web Signatures)? COSE is optimized for binary data and drastically smaller payload sizes, making it highly efficient for high-frequency operational heartbeats, SCITT receipts, and constrained edge environments compared to the verbose nature of JWS.

Transparency and SCITT

21. What is SCITT? Supply Chain Integrity, Transparency, and Trust. An IETF architecture defining mechanisms for creating an immutable, tamper-evident, decentralized registry of software supply chain and operational claims1. 22. What is a Transparency Log? An append-only cryptographic ledger (often structured as a Merkle tree) where records can only be added. Past records cannot be modified or deleted without fundamentally breaking the cryptographic hashes of all subsequent records. 23. What is a SCITT Receipt? A cryptographic proof (specifically an inclusion proof) returned by a SCITT transparency service. It demonstrates mathematically that a specific signed statement has been permanently recorded in the immutable ledger2. 24. How does SCITT prevent equivocation (split-brain lies)? Because the ledger is a globally verifiable Merkle tree, a service provider cannot show one version of history to one auditor and a different version to another without the cryptographic root hashes conflicting and exposing the lie. 25. What is Evidence Freshness? The concept that cryptographic proofs must be recent to be valid. Evidence must include timestamps and nonces, and expire rapidly, to prevent attackers from replaying old, valid operational signatures during a current outage. 26. How is a missing heartbeat handled cryptographically? In Patefacere's architecture, a missing heartbeat sequence number in the transparency log is not ignored; it is mathematically treated as a definitive system incident or outage, requiring a formal correction claim. 27. What is a Transparent Statement? A Signed Statement that has been augmented with a valid SCITT Receipt, proving it has been successfully accepted and anchored into a Transparency Service25. 28. Does SCITT require a cryptocurrency blockchain? No. SCITT relies on verifiable data structures (like Merkle trees) and hash-chaining similar to Certificate Transparency logs. It can be run centrally or federally without requiring energy-intensive, proof-of-work consensus blockchains2. 29. What prevents the Transparency Service itself from lying? The Transparency Service periodically publishes its root hash to independent observers. If it alters past records, the new root hash will not match the chain of previous receipts, exposing the tampering immediately to all participants. 30. How does SCITT handle highly sensitive data? SCITT is inherently payload-agnostic. Sensitive data is kept off-chain, and only the cryptographic hash of the data (the claim) is registered in the public transparency log. This preserves strict privacy while ensuring data integrity2.

Operations, Compliance, and Illinois Law

31. What constitutes "Operational Availability" in this architecture? Not merely network ping success, but the continuous, cryptographically verified execution of the authorized software binary, interacting correctly with its environment and generating valid heartbeats. 32. Why separate software implementation from deployment in the ontology? Because a flawless, SLSA Level 4 implementation can be deployed insecurely (e.g., given root privileges or exposed to the public internet by misconfiguration). Both phases require independent, verifiable evidence. 33. What is BIPA, and how does Patefacere avoid violating it? The Illinois Biometric Information Privacy Act (740 ILCS 14\) strictly regulates the collection and storage of biometric data15. Patefacere avoids violations by never publishing or storing raw PII or biometrics in evidence logs, relying solely on cryptographic hashes of state. 34. What is PIPA? The Illinois Personal Information Protection Act (815 ILCS 530), which dictates data security requirements and strict breach notification standards15. Patefacere's continuous cryptographic state monitoring accelerates breach detection to well within PIPA's 45-day notification requirement. 35. How does the Local Records Act (50 ILCS 205\) apply to Patefacere? It dictates the preservation and destruction of public records11. Patefacere must ensure that transparency receipts and operational logs align with the state-approved retention schedules and are not destroyed prematurely30. 36. Are SCITT receipts considered public records under the LRA? Yes. If generated by a local government agency in connection with public business, they meet the definition of "born-digital electronic material" and must be managed according to LRA disposal rules11. 37. How does Patefacere prove an incident is resolved? By submitting a formal correction claim to the SCITT log containing the digest of the root-cause analysis and successfully resuming the sequential heartbeat generation. 38. Can outside parties audit Patefacere without an NDA? Yes. By verifying the public SCITT ledger and checking the RFC 9421 HTTP signatures, anyone can audit the systemic integrity without accessing proprietary code or private user data. 39. Why is manual status reporting obsolete? Because it is subject to human error, delays, and PR-driven obfuscation. Cryptographic evidence provides objective, mathematically undeniable reality that cannot be spun. 40. How do we ensure API consumers trust the data? API consumers validate the RFC 9530 Content-Digest and the RFC 9421 Signature on every single response, ensuring the payload is authentic and unaltered by any intermediary6.

19\. Twenty-Five Direct Answers#

1. Does Patefacere use MD5 for hashing? No. MD5 is cryptographically broken and explicitly prohibited by RFC 9530 for Integrity fields; Patefacere uses SHA-256 or SHA-51222. 2. Can TLS replace HTTP Message Signatures? No. TLS only protects transit between direct network hops; it does not provide the end-to-end integrity required by RFC 942123. 3. Does reaching an endpoint mean the observer is authorized? No. Reachability only proves network connectivity; authorization requires verifying the cryptographic signature6. 4. Is an SBOM sufficient to prove operational security? No. An SBOM only proves what ingredients are in a package, not that the package is currently executing securely. 5. Does Patefacere publish live citizen PII to prove operations? No. Operational evidence relies entirely on cryptographic state hashes, not on exposing PII or raw application totals. 6. Can a SCITT transparency log be silently altered? No. Altering a past entry changes the cryptographic hashes of all subsequent entries, immediately revealing the tamper2. 7. Are in-toto attestations strictly formatted? Yes. They use a fixed Statement layer binding a subject (artifact) to a predicate (claim)4. 8. Does SLSA guarantee that the source code has no vulnerabilities? No. SLSA provenance guarantees that the binary was built from a specific source without tampering, not that the source itself is bug-free5. 9. Is JSON inherently suitable for cryptographic hashing? No. Its lack of key ordering and formatting rules makes it non-deterministic, necessitating RFC 8785 (JCS)17. 10. Does RFC 9421 protect the HTTP body directly? No. RFC 9421 protects headers and metadata; it relies on RFC 9530 Content-Digest to protect the body24. 11. Can a missing heartbeat indicate an incident? Yes. The verifiable absence of an expected cryptographic claim mathematically constitutes an incident. 12. Does a reproducible build require a hermetic environment? Yes. Strict network isolation and fixed dependencies are required to achieve deterministic, bit-for-bit identical output. 13. Does the Local Records Act allow deleting public records at will? No. Disposal requires explicit approval from the Local Records Commission and a submitted Disposal Certificate11. 14. Are electronic signatures legally binding in Illinois? Yes. Under the Electronic Commerce Security Act (5 ILCS 175), electronic signatures carry legal equivalence to traditional written signatures14. 15. Does the @signature-params field get signed in RFC 9421? Yes. It is always the last line of the signature base to prevent tampering with the signature metadata10. 16. Can Patefacere use a self-signed certificate for public SCITT receipts? No. Public verifiability requires a root of trust anchored to a recognized constitutional or delegated authority. 17. Does Content-Digest hash the data before or after compression? Content-Digest hashes the data exactly as it travels on the wire (after compression like gzip)22. 18. Can multiple signatures be applied to a single DSSE envelope? Yes. The DSSE specification explicitly supports and recommends multiple signatures on a single payload13. 19. Does an in-toto layout prevent unauthorized actors from deploying? Yes. If the verifier strictly enforces the layout, it will reject deployments lacking signatures from authorized keys3. 20. Is BIPA compliance optional for Illinois organizations? No. BIPA is a stringent biometric privacy law with severe civil penalties for violations15. 21. Do third-party auditors need access to source code for Level 4 maturity? No. They verify the mathematical proofs (SCITT receipts and JCS hashes) without needing the raw source code1. 22. Can a signature from RFC 9421 be replayed against another endpoint? No. Including the @target-uri and a nonce in the covered components prevents cross-endpoint replay attacks24. 23. Is JSON Canonicalization Scheme (JCS) widely implemented? Yes. It is supported by multiple open-source implementations across languages like Go, Python, and Elixir28. 24. Does Patefacere generate negative evidence manually? No. Negative evidence (like a missed heartbeat) is mathematically derived by the automated absence of a sequence number in the ledger. 25. Is "No published incident" proof of a healthy system? No. An absence of a published incident without continuous cryptographic proof of uptime is meaningless in an assurance context.

20\. Primary-Source Bibliography#

This research architecture relies heavily on formal Internet Engineering Task Force (IETF) specifications, software supply chain frameworks, and Illinois state statutes to construct its assurance models.

• RFC 9421: HTTP Message Signatures. (2024). Defines the standard mechanism for end-to-end authentication and integrity of HTTP message components, utilizing the @signature-params canonicalization method to prevent intermediary tampering6.
• RFC 9530: Digest Fields. (2024). Obsoletes RFC 3230\. Specifies the Content-Digest and Repr-Digest headers, dictating how payloads must be hashed (excluding MD5) to provide payload integrity across HTTP exchanges7.
• RFC 8785: JSON Canonicalization Scheme (JCS). (2020). Provides the rigorous serialization method required to make JSON data deterministic. Essential for ensuring that cryptographic hashes of operational evidence do not fail due to arbitrary whitespace or property sorting17.
• RFC 9052: CBOR Object Signing and Encryption (COSE). (2022). Specifies the cryptographic encapsulation format used by SCITT receipts and highly efficient operational heartbeats, minimizing payload weight while providing robust integrity26.
• draft-ietf-scitt-architecture / RFC 9943\. (2024). An Architecture for Trustworthy and Transparent Digital Supply Chains. Defines the roles of Issuers, Notaries, and Transparency Services in generating append-only, tamper-evident ledgers for software attestations1.
• SLSA Provenance Specification v1.0. Specifies the exact JSON schema (https://slsa.dev/provenance/v1) for proving how an artifact was built, replacing assumptions with verifiable evidence of the compilation environment5.
• in-toto Attestation Framework v1.0. The overarching metadata format defining Statement, Subject, and Predicate layers. This architecture is the core vehicle carrying Patefacere's operational claims into the SCITT ledger3.
• Illinois Local Records Act (50 ILCS 205). The state statute governing the definition, preservation, and disposal of public records, explicitly extending to "born-digital electronic material" and dictating how cryptographic transparency receipts are managed within government deployments11.
• Illinois Electronic Commerce Security Act (5 ILCS 175). The legal framework in Illinois establishing that electronic records and digital signatures satisfy legal requirements for original, written signatures, underpinning the "Legal Effect" layer of the ontology14.
• Illinois Personal Information Protection Act (PIPA \- 815 ILCS 530). The state's primary cybersecurity law requiring reasonable safeguards for personal data and strict breach notifications within 45 days15.

21\. A 70-Term Glossary#

1. Algorithm Agility: The ability of a protocol or system to migrate from older cryptographic algorithms to newer ones seamlessly as vulnerabilities are discovered. 2. Append-only Log: A data structure where new data can only be added to the end, preventing modification or deletion of past entries. 3. Artifact: A discrete piece of software, such as a compiled binary, container image, or source tarball, usually identified by a cryptographic digest. 4. Assurance Case: A structured argument, supported by evidence, intended to justify that a system operates securely and correctly. 5. Attestation: A cryptographically signed metadata statement claiming that a specific event occurred or a property holds true. 6. Base64url: An encoding scheme that represents binary data in an ASCII string format suitable for use in URLs and HTTP headers. 7. BIPA: Biometric Information Privacy Act (740 ILCS 14); an Illinois law strictly regulating the collection and storage of biometric data. 8. Build Caches: Temporary storage used by compilers to speed up builds; must be isolated to prevent poisoning in reproducible builds. 9. BuildDefinition: The parameters and instructions used by a build system to compile source code into an artifact, as defined in SLSA. 10. Builder ID: A unique cryptographic identifier representing the entity or system that performed a build and generated provenance. 11. Canonicalization: The process of converting data into a standard, deterministic format for cryptographic hashing. 12. CBOR: Concise Binary Object Representation (RFC 8949); a data format designed for extremely small code and message sizes. 13. Certificate Transparency: An ecosystem where all issued TLS certificates are logged to publicly auditable, append-only logs. 14. Code Signing: The process of digitally signing executables to confirm the software author and guarantee the code has not been altered. 15. Content-Digest: An HTTP header (RFC 9530\) containing a hash of the literal message content bytes transmitted on the wire. 16. COSE: CBOR Object Signing and Encryption (RFC 9052); provides cryptographic operations optimized for CBOR data. 17. CycloneDX: A lightweight Software Bill of Materials (SBOM) standard designed specifically for use in application security contexts. 18. Data Custody: The logical and physical control an entity has over the data it stores and processes. 19. Deterministic Build: A compilation process that always produces an identical binary when given the same source and environment. 20. DSSE: Dead Simple Signing Envelope; a standard for wrapping arbitrary payloads with cryptographic signatures and type indicators. 21. ECMA-262: The ECMAScript language specification, which dictates the strict serialization formatting used by JCS for numbers. 22. End-to-end Integrity: A cryptographic guarantee that data sent from a source arrives at its final destination completely unmodified. 23. Envelope: A data structure that encapsulates a payload alongside its metadata and cryptographic signatures. 24. Evidence Freshness: The concept that cryptographic proofs must be recent to be valid, heavily mitigating replay attacks. 25. External Parameters: The untrusted inputs to a build process (e.g., Git URLs) that must be recorded in SLSA provenance. 26. Federation: A system design where multiple independent entities operate nodes that interoperate without a central authority. 27. Hash-chain: A sequential series of cryptographic hashes where each hash incorporates the previous one, ensuring chronological integrity. 28. HMAC: Hash-based Message Authentication Code; a method utilizing a cryptographic hash function and a secret cryptographic key. 29. HTTP Message Signatures: RFC 9421; a protocol for generating and verifying signatures over components of an HTTP message. 30. Identity Binding: The cryptographic linkage between a digital key and a real-world legal or operational entity. 31. IETF: Internet Engineering Task Force; the organization that develops and promotes voluntary Internet standards. 32. I-JSON: Internet JSON (RFC 7493); a restricted profile of JSON designed to maximize interoperability and security. 33. ILCS: Illinois Compiled Statutes; the codified laws of the state of Illinois. 34. Independent Review: Auditing of a system performed by a party entirely separate from the developers or operators of that system. 35. in-toto: A framework for securing software supply chains by generating cryptographic attestations for each step in the layout. 36. Integrity Field: The collective term used in RFC 9530 for HTTP fields that provide cryptographic hashes (e.g., Content-Digest). 37. Internal Parameters: Trusted parameters generated by the build platform itself during execution. 38. JCS: JSON Canonicalization Scheme (RFC 8785); standardizes JSON serialization to produce identical byte outputs for signing. 39. JSON: JavaScript Object Notation; a lightweight data-interchange format. 40. JWS: JSON Web Signature; a standard representing content secured with digital signatures using JSON-based data structures. 41. JWK: JSON Web Key; a JSON data structure representing a cryptographic key. 42. Key Identifier (keyid): Metadata within a signature envelope indicating which public key should be used for verification. 43. Local Records Act (LRA): Illinois statute (50 ILCS 205\) regulating the preservation and destruction of public records. 44. Message Authentication Code: A short piece of information used to authenticate a message and provide integrity. 45. mTLS: Mutual Transport Layer Security; requires both client and server to authenticate each other using certificates. 46. Negative Evidence: Cryptographic proof derived from the absence of expected positive events (e.g., missed heartbeat sequences). 47. Nonce: A random or semi-random number used only once in a cryptographic communication to prevent replay attacks. 48. Operational Availability: The real-world state of a service being reachable, functional, and executing its authorized logic. 49. Ontology: A set of concepts and categories in a subject area showing their properties and the relations between them. 50. Outside-in Observation: The ability of an external party to securely audit the state of a system without privileged internal access. 51. PIPA: Personal Information Protection Act; an Illinois law dictating data security and breach notification standards. 52. Predicate: The portion of an in-toto statement containing the specific claim or metadata (e.g., test results, provenance). 53. PredicateType: A URI string identifying the exact schema of the Predicate object in an attestation. 54. Provenance: The verifiable origin and history of a software artifact, primarily documenting how it was built. 55. Reachability: A network state indicating that packets can successfully travel from a client to a server. 56. Receipt: A cryptographic inclusion proof issued by a SCITT Transparency Service indicating a claim is logged. 57. Repr-Digest: An HTTP header (RFC 9530\) containing the hash of a selected representation before content-encoding is applied. 58. Reproducible Build: A build system guaranteeing identical binaries from identical source code. 59. ResourceDescriptor: A schema within in-toto used to describe an artifact, primarily using its cryptographic digest. 60. Ryū algorithm: An algorithm for converting floating-point numbers to decimal strings, used strictly within JCS (RFC 8785). 61. SCITT: Supply Chain Integrity, Transparency, and Trust; an architecture for transparent registries of supply chain claims. 62. Service Truth: The objective, cryptographically provable reality of a deployed system's operations and authorizations. 63. SHA-256: A cryptographic hash function that outputs a 256-bit digest, standard across SLSA, SCITT, and digest RFCs. 64. Signature Base: The reconstructed, canonical byte sequence that is mathematically signed in RFC 9421\. 65. Sigstore: An open-source project facilitating easy, transparent signing of software release artifacts without long-term keys. 66. SLSA: Supply-chain Levels for Software Artifacts; a framework grading the integrity of the software build process. 67. SPDX: Software Package Data Exchange; an ISO-standard format for communicating SBOM information. 68. Subject: The array of artifacts (identified by hashes) that an in-toto attestation is making a claim about. 69. Transparency Service: A network node operating an append-only ledger that registers and provides receipts for claims. 70. Want-Content-Digest: An HTTP header allowing a client to request that the server respond with a specific digest algorithm.

Works cited#

1. draft-ietf-scitt-architecture-11, https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-11 2. SCITT: Supply Chain Integrity, Transparency and Trust \- Conserver.io, https://www.conserver.io/deep-dives/scitt-supply-chain-integrity-transparency-and-trust 3. in-toto and SLSA, https://slsa.dev/blog/2023/05/in-toto-and-slsa 4. attestation/spec/v1/statement.md at main · in-toto/attestation \- GitHub, https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md 5. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0/provenance 6. RFC 9421: HTTP Message Signatures, https://www.rfc-editor.org/info/rfc9421/ 7. RFC 9530: Digest Fields, https://www.rfc-editor.org/info/rfc9530/ 8. In-Toto Supply Chain Security Framework Documentation, https://docs.devguard.org/explanations/supply-chain-security/in-toto-framework/ 9. attestation/spec/predicates/link.md at main · in-toto/attestation \- GitHub, https://github.com/in-toto/attestation/blob/main/spec/predicates/link.md 10. HTTP Message Signatures \- RFC 9421 Guide, https://openlinksw.com/data/html/http-signatures-infographic.html 11. Guide to the Illinois Local Records Act \- Citizen Advocacy Center, https://sealion-raccoon-22dm.squarespace.com/s/final\_guide\_to\_illinois\_local\_records\_act-wrsk.pdf 12. Local Government Law, https://zrfmlaw.com/wp-content/uploads/Local-Records-Act.pdf 13. envelope.md \- in-toto/attestation \- GitHub, https://github.com/in-toto/attestation/blob/main/spec/v1/envelope.md 14. Electronic Signatures – The Enforceability of E-mails and Texts as “Signed Writings”, https://www.lauriebrennan.com/blog/electronic-signatures-the-enforceability-of-e-mails-and-texts-as-signed-writings/ 15. Illinois Cybersecurity Laws You Should Know (2026) \- PivIT Strategy, https://pivitstrategy.com/illinois-cybersecurity-laws-you-should-know-2026/ 16. draft-ietf-scitt-architecture-10 \- An Architecture for Trustworthy and Transparent Digital Supply Chains \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/10/ 17. RFC 8785 \- JSON Canonicalization Scheme (JCS) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc8785 18. RFC 8785: JSON Canonicalization Scheme (JCS), https://www.rfc-editor.org/info/rfc8785/ 19. JSON Canonicalization Scheme (JCS) Projects \- AI Tinkerers \- Atlanta, https://atlanta.aitinkerers.org/technologies/json-canonicalization-scheme-jcs 20. The JSON Canonicalisation Scheme (RFC 8785\) in action and how to secure JSON objects with HMAC \- Connect2id, https://connect2id.com/blog/how-to-secure-json-objects-with-hmac 21. RFC 9530 \- Digest Fields \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9530/ 22. Content-Digest \- Expert Guide to HTTP headers, https://http.dev/content-digest 23. RFC 9421 \- HTTP Message Signatures \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9421 24. Understanding HTTP Message Signatures \- Blog Notes, https://blog.vitalvas.com/post/2025/12/12/understanding-http-message-signatures/ 25. draft-ietf-scitt-scrapi-11 \- Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ietf-scitt-scrapi/ 26. CBOR Object Signing and Encryption \- IETF Datatracker, https://datatracker.ietf.org/doc/charter-ietf-cose/ 27. README.md \- http\_digest 0.1.0 \- Hex.pm, https://hex.pm/packages/http\_digest/0.1.0/files/README.md 28. json-canon: A Strict RFC 8785 Implementation in Go for Deterministic JSON, https://dev.to/lenny321/json-canon-a-strict-rfc-8785-implementation-in-go-for-deterministic-json-3mfg 29. Sigstore Bundle Format, https://docs.sigstore.dev/about/bundle/ 30. Records Inventory and Disposal \- Cook County, https://www.cookcountyil.gov/service/records-inventory-and-disposal 31. Managing Your Records & the Local Records Act: A Quick Guide for Disposing of Local Records \- Township Officials of Illinois, https://www.toi.org/Resources/2dea909f-c310-4edc-82fc-8fdddb51edc1/Managing%20Your%20Local%20Records%20Guide%202025.pdf 32. rfc8785 \- Hex.pm, https://hex.pm/packages/rfc8785/1.0.0 33. RFC 9338: CBOR Object Signing and Encryption (COSE): Countersignatures, https://www.rfc-editor.org/info/rfc9338/