Proving What Patefacere Actually Operates: Operational Evidence, Service Truth, Software Provenance, and Public Release Assurance

Full report

On this page

The modern digital supply chain and public infrastructure ecosystems face an existential crisis of trust. Traditional models of operational assurance rely heavily on point-in-time audits, static documentation, and perimeter-based network security. These legacy paradigms fail to provide continuous, mathematically verifiable proof that a specific software artifact is genuinely operating in a defined environment, under authorized conditions, and without malicious interference. When a critical entity—conceptually designated herein as Patefacere (derived from the Latin infinitive meaning "to disclose" or "to bring to light")—operates infrastructure, it must transcend trust-by-assertion. The architecture must instead enforce trust-by-cryptographic-evidence. This comprehensive report details the architectural, cryptographic, and operational mechanisms required to establish an unbroken chain of custody from source code authoring to live, public service execution. By synthesizing the Supply Chain Integrity, Transparency, and Trust (SCITT) architecture defined in RFC 99431, the software supply chain levels for software artifacts (SLSA)2, the in-toto attestation framework4, and HTTP Message Signatures standardized in RFC 94216, this blueprint specifies a system where every state change is an immutable, publicly verifiable event. It operates on the principle that the publication of human-oriented business metrics—such as live citizen counts, passport applications, credential totals, or registry volumes—does not constitute operational evidence and poses severe privacy risks. True operational evidence relies exclusively on systemic metadata, cryptographic digests, and hardware-backed execution measurements.

1. A Service-Truth Ontology

To systematically prevent categorical errors in system auditing and public assurance, Patefacere relies on a rigorous Service-Truth Ontology. This ontological framework segregates the distinct dimensions of a system's existence, ensuring that a cryptographic claim regarding one dimension (e.g., software compilation) is never falsely presented as evidence for another (e.g., operational availability). The ontology encompasses nine critical dimensions:

1. Constitutional or Delegated Authority: This dimension represents the legal, statutory, or organizational mandate that permits the system to exist, process data, and act. In governmental contexts, this parallels legislative mandates such as the Illinois Local Records Act (50 ILCS 205), which governs the retention, disposal, and transparency of born-digital electronic material8. The authority dictates the boundaries of lawful operation, establishing the foundational right of the system to execute its designated functions.

2. Public Documentation: The human-readable assertions, policies, specifications, and architectural diagrams describing what the system is intended to do. While necessary for human comprehension, this dimension provides zero cryptographic assurance and serves merely as the hypothesis that subsequent cryptographic evidence must prove.

3. Software Implementation: The source code, dependency trees, and resulting compiled binary artifacts. Evidence in this dimension relies on reproducible builds, Software Bill of Materials (SBOMs) such as SPDX or CycloneDX formats, and SLSA provenance, answering precisely how the artifact was constructed3.

4. Deployment: The discrete act of placing the compiled, verified software artifact into a hosting environment or orchestrator. Evidence is generated via deployment attestations, often encapsulated within in-toto links, proving that the infrastructure control plane accepted the authorized binary4.

5. Authorized Observation: The capacity for specific internal or external entities to monitor the system's state. Network reachability does not equate to authorized observation. Observation requires cryptographic authorization, implemented via RFC 9421 HTTP Message Signatures, ensuring that telemetry is both authentic and requested by a verified principal6.

6. Operational Availability: The real-time, dynamic execution state of the deployed software. This requires cryptographic heartbeat attestations proving memory integrity, configuration consistency, and active processing capability, moving beyond simplistic network uptime checks.

7. Data Custody: The cryptographic binding of the operating system to the data it holds and processes, ensuring that data is neither altered in transit nor silently dropped, maintaining compliance with data retention and protection statutes10.

8. Evidence Freshness: The temporal validity of the operational evidence. SCITT ledgers provide continuous temporal proofs, which must be augmented by external temporal anchoring (e.g., Bitcoin OP\_RETURN anchoring via OpenTimestamps) to ensure the timeline itself is not manipulated by a compromised transparency service operator11.

9. Legal Effect: The binding nature of the system's actions on external entities, derived from the verifiable, cryptographic intersection of Constitutional Authority and Operational Evidence. It is the final dimension where digital actions are recognized by human legal frameworks.

2. An Operational-Evidence Panel Specification

The Operational-Evidence Panel serves as the public-facing verification interface for Patefacere. It surfaces cryptographic proofs of the infrastructure's state without leaking Personally Identifiable Information (PII) or business payload data. It fundamentally shifts the paradigm from a traditional status page (which relies on manual human updates) to an automated, cryptographically guaranteed dashboard. The architecture of the panel is entirely decoupled from Patefacere's internal execution environment. It operates exclusively by continuously reading from an independent SCITT Transparency Service (TS)1. When a component within Patefacere undergoes a state change or emits a health heartbeat, it formats this telemetry as a CBOR Object Signing and Encryption (COSE) payload and submits it to the TS. The TS validates the signature against a pre-registered policy, appends the statement to its verifiable data structure (VDS), and returns a SCITT receipt (application/scitt-receipt+cose)1. The Operational-Evidence Panel queries these receipts, parses the payload type, and translates the cryptographic verifiable data into human-readable verification chains. The user interface prominently displays the continuous flow of evidence freshness by surfacing external temporal anchors11. If Patefacere experiences an outage, the panel does not require an operator to click a button; the cessation of fresh, SCITT-backed health attestations mathematically triggers a degraded or offline status indication. The panel enforces an absolute prohibition on displaying transactional data, user volumes, or database row counts, restricting its scope entirely to infrastructure and software integrity metadata.

3. 32 Capability-Level Evidence Records

Capability-level evidence records document the distinct authorizations and functional states of the Patefacere architecture. Each record maps to a specific event in the software supply chain or operational lifecycle, bound by cryptographic signatures.

4. Software-Release Manifest Schema

The Software-Release Manifest binds SBOM elements to the SCITT architecture, utilizing the application/scitt-statement+cose structure12. The JSON payload encapsulated within the COSE envelope acts as the definitive cryptographic declaration of a software release.

JSON { "$schema": "http://json-schema.org/draft-07/schema\#", "title": "Software Release Manifest", "type": "object", "properties": { "\_type": { "const": "https://patefacere.org/release-manifest/v1" }, "releaseVersion": { "type": "string" }, "releaseManager": { "type": "string", "description": "KeyID of the authorized releaser" }, "artifacts": { "type": "array", "items": { "type": "object", "properties": { "name": { "type": "string" }, "digest": { "type": "object", "properties": { "sha256": { "type": "string" } }, "required": \["sha256"\] }, "sbomRef": { "type": "string", "format": "uri" }, "provenanceRef": { "type": "string", "format": "uri" } }, "required": \["name", "digest", "sbomRef", "provenanceRef"\] } }, "policyClearance": { "type": "array", "items": { "type": "string", "format": "uri" } } }, "required": \["\_type", "releaseVersion", "releaseManager", "artifacts", "policyClearance"\] }

The manifest schema requires the rigorous declaration of the artifact's exact SHA-256 digest alongside URI references to its SBOM (SPDX/CycloneDX) and its build provenance. The policyClearance array includes URIs to cryptographic endorsements from policy engines (e.g., proving vulnerability scans passed). Once populated, this JSON object undergoes JSON Canonicalization Scheme (JCS) normalization, is base64-encoded, and wrapped in a COSE\_Sign1 envelope before being submitted to the Transparency Service1. The resulting receipt proves exactly what software was deemed authorized for release, locking the supply chain prior to deployment.

5. Build-Provenance Schema

The build provenance utilizes the SLSA v1.0 standard encapsulated in an in-toto attestation envelope2. It provides the verifiable answer to how the artifact listed in the release manifest was created.

JSON { "$schema": "http://json-schema.org/draft-07/schema\#", "title": "Build Provenance SLSA v1.0", "type": "object", "properties": { "\_type": { "const": "https://in-toto.io/Statement/v1" }, "subject": { "type": "array", "items": { "type": "object", "properties": { "name": { "type": "string" }, "digest": { "type": "object", "properties": { "sha256": { "type": "string" } } } }, "required": \["name", "digest"\] } }, "predicateType": { "const": "https://slsa.dev/provenance/v1" }, "predicate": { "type": "object", "properties": { "buildDefinition": { "type": "object", "properties": { "buildType": { "type": "string" }, "externalParameters": { "type": "object" }, "resolvedDependencies": { "type": "array", "items": { "type": "object", "properties": { "uri": { "type": "string" }, "digest": { "type": "object" } } } } }, "required": \["buildType", "externalParameters", "resolvedDependencies"\] }, "runDetails": { "type": "object", "properties": { "builder": { "type": "object", "properties": { "id": { "type": "string" } } }, "metadata": { "type": "object", "properties": { "invocationId": { "type": "string" }, "startedOn": { "type": "string", "format": "date-time" }, "finishedOn": { "type": "string", "format": "date-time" } } } }, "required": \["builder", "metadata"\] } }, "required": \["buildDefinition", "runDetails"\] } }, "required": \["\_type", "subject", "predicateType", "predicate"\] }

This schema adheres to the in-toto v1.0 specification, wrapping the SLSA v1.0 predicate. The subject definitively identifies the compiled artifact. The buildDefinition outlines the exact environmental parameters and external dependencies injected into the build, while runDetails asserts the identity of the builder (e.g., a specific, hardened GitHub Actions runner)3. This payload is signed using a Dead Simple Signature Envelope (DSSE), guaranteeing that the metadata cannot be tampered with post-compilation15.

6. Deployment-Observation Schema

Deployment observation bridges the gap between static software artifacts and dynamic execution, confirming that a specific verified binary was launched in the production environment.

JSON { "$schema": "http://json-schema.org/draft-07/schema\#", "title": "Deployment Observation", "type": "object", "properties": { "\_type": { "const": "https://in-toto.io/Statement/v1" }, "subject": { "type": "array", "description": "The specific binary deployed, referencing the Release Manifest." }, "predicateType": { "const": "https://patefacere.org/deployment-observation/v1" }, "predicate": { "type": "object", "properties": { "environmentId": { "type": "string" }, "orchestratorId": { "type": "string", "description": "e.g., Kubernetes cluster ARN" }, "deploymentTime": { "type": "string", "format": "date-time" }, "configurationDigest": { "type": "string", "description": "Hash of ConfigMaps/Secrets" }, "nodeIdentifier": { "type": "string" } }, "required": \["environmentId", "orchestratorId", "deploymentTime", "configurationDigest"\] } }, "required": \["\_type", "subject", "predicateType", "predicate"\] }

Generated by the infrastructure orchestrator (e.g., a Kubernetes admission controller), this attestation proves that the infrastructure control plane authorized the binary execution. The configurationDigest is critical, as a secure binary paired with a malicious configuration file results in a compromised system. This schema guarantees configuration binding.

7. Public Status Schema

This schema structures the system's public health endpoints. Crucially, HTTP responses serving this schema must be signed using RFC 9421 HTTP Message Signatures to prevent intermediary tampering by CDNs or proxies7.

JSON { "$schema": "http://json-schema.org/draft-07/schema\#", "title": "Public Status", "type": "object", "properties": { "status": { "type": "string", "enum": \["OPERATIONAL", "DEGRADED", "OUTAGE", "MAINTENANCE", "QUIESCENCE"\] }, "timestamp": { "type": "string", "format": "date-time" }, "componentHealth": { "type": "array", "items": { "type": "object", "properties": { "component": { "type": "string" }, "state": { "type": "string" }, "lastEvidenceHash": { "type": "string", "description": "Pointer to SCITT receipt" } }, "required": \["component", "state", "lastEvidenceHash"\] } }, "scittSequenceNumber": { "type": "integer" } }, "required": \["status", "timestamp", "componentHealth", "scittSequenceNumber"\] }

The public status schema ties the immediate operational reality of the system back to the immutable transparency ledger via the scittSequenceNumber and lastEvidenceHash. This prevents a scenario where a compromised edge server simply returns an unauthorized { "status": "OPERATIONAL" } JSON blob. The client application must verify the HTTP Message Signature over this payload and the Content-Digest17 to guarantee the telemetry originated from the enclave holding the ephemeral operational key.

8. Incident and Correction Schema

Transparency requires that failures are documented with the same cryptographic rigor as successes. This schema structures negative evidence on the immutable ledger.

JSON { "$schema": "http://json-schema.org/draft-07/schema\#", "title": "Incident and Correction", "type": "object", "properties": { "\_type": { "const": "https://in-toto.io/Statement/v1" }, "subject": { "type": "array", "description": "The impacted system components" }, "predicateType": { "const": "https://patefacere.org/incident/v1" }, "predicate": { "type": "object", "properties": { "incidentId": { "type": "string", "format": "uuid" }, "severity": { "type": "string", "enum": \["SEV-1", "SEV-2", "SEV-3"\] }, "detectionTime": { "type": "string", "format": "date-time" }, "description": { "type": "string" }, "correction": { "type": "object", "properties": { "appliedPatchHash": { "type": "string" }, "resolutionTime": { "type": "string", "format": "date-time" }, "postIncidentReviewUri": { "type": "string", "format": "uri" } }, "required": \["appliedPatchHash", "resolutionTime"\] } }, "required": \["incidentId", "severity", "detectionTime", "description"\] } }, "required": \["\_type", "subject", "predicateType", "predicate"\] }

This attestation prevents historical revisionism. An operator cannot delete a database log to hide downtime; the incident is immutably anchored to the SCITT Transparency Service and, subsequently, to an external ledger like Bitcoin via OpenTimestamps11. The appliedPatchHash ensures the remediation directly correlates to a new Software-Release Manifest.

9. Assurance-Claim Schema

The assurance-claim schema maps the raw cryptographic operational reality back to the human-readable Service-Truth Ontology, allowing auditors to sign off on specific system states.

JSON { "$schema": "http://json-schema.org/draft-07/schema\#", "title": "Assurance Claim", "type": "object", "properties": { "claimId": { "type": "string", "format": "uuid" }, "ontologyDimension": { "type": "string", "enum": \["Authority", "Documentation", "Implementation", "Deployment", "Observation", "Availability", "Custody", "Freshness", "LegalEffect"\] }, "claimText": { "type": "string" }, "evidenceURIs": { "type": "array", "items": { "type": "string", "format": "uri" }, "description": "Links to SCITT receipts backing the claim" }, "auditorIdentity": { "type": "string", "description": "KeyID of the independent reviewer" }, "auditorSignature": { "type": "string" } }, "required": \["claimId", "ontologyDimension", "claimText", "evidenceURIs", "auditorIdentity", "auditorSignature"\] }

By explicitly declaring the ontologyDimension, this schema forces the auditor to classify their claim, preventing the common fallacy of utilizing a deployment artifact as proof of operational availability.

10. 64 Evidence and Status Fixtures

To validate the architecture, the following 64 specific structured data fixtures must be capable of generation, transmission, and verification within the system.

11. 32 Incident and Negative-Evidence Fixtures

A transparent architecture must cryptographically prove its failures. These fixtures represent the negative evidence necessary to demonstrate that the system does not censor operational realities.

12. Reproducible-Build Maturity Model

Patefacere requires a rigorous, strictly defined build process modeled after the SLSA framework3. The core objective is to ensure that the software artifact deployed is precisely the artifact audited, eliminating the threat of a compromised build server injecting malicious code.

To achieve Level 4, Patefacere infrastructure must compile its critical components in environments devoid of external network access, resolving all dependencies from verified, internal cryptographic caches. This deterministic rebuilding process ensures that any third-party auditor possessing the source code can regenerate the exact SHA-256 digest listed in the SCITT transparency ledger, mathematically proving the absence of backdoors.

13. Independent-Review Maturity Model

To establish systemic trust, the auditing and review of Patefacere must transition from internal checklists and static PDF reports to mathematically verifiable public records that integrate with the overall cryptographic architecture.

At Level 4, the auditor no longer inspects the system on an annual basis. Instead, they provide a cryptographic policy definition (e.g., using Rego). The Patefacere infrastructure continually evaluates its state against this policy, emitting signed attestations of compliance. The independent reviewer's role shifts from inspecting the system to auditing the cryptographic policy engine and verifying the external temporal anchors on the SCITT ledger.

14. Package Present Is Not Service Operational

A pervasive and dangerous fallacy in software supply chain management is conflating the existence of a binary package with the operational reality of a service. Moving a signed, SLSA Level 4 container image into a production orchestration environment proves only custody and deployment, not execution. For Patefacere, distinguishing these states within the Service-Truth Ontology is paramount. A package present in a deployment volume is functionally inert. To cross the threshold into "Service Operational," the system must actively issue cryptographic attestations of its execution state. This involves hardware-backed Trusted Execution Environments (TEEs) or Secure Enclaves measuring the memory state of the loaded binary and signing a heartbeat13. Without this distinction, an auditor or public dashboard might read a valid Software-Release Manifest and a successful Deployment-Observation attestation, subsequently assuming the system is secure and running. In reality, a malicious actor or infrastructure failure could have prevented the secure binary from launching, substituting it with a rogue process. Operational evidence demands that the running process itself possesses a unique, ephemeral cryptographic key generated at startup, which it uses to sign its own telemetry. The presence of the package is a prerequisite; the signed heartbeat is the proof of life.

15. Reachable Is Not Authorized to Observe

Network reachability—such as responding to an ICMP ping, a basic TCP handshake, or a generic HTTP 200 OK on a status endpoint—is frequently misinterpreted as proof of operational health or authorized telemetry. In modern zero-trust architectures, being able to reach an endpoint provides no cryptographic proof of the system's identity, state, or the authenticity of the data returned19. Patefacere requires "Authorized Observation," implemented strictly via RFC 9421 (HTTP Message Signatures)7. When an authorized monitor queries the Patefacere status endpoint, the service does not merely return a JSON body. It constructs a canonical signature base—including essential components like @method, @target-uri, and content-digest (incorporating RFC 9530 to protect the HTTP body)—and signs this base with its ephemeral operational key6. The observer then validates this signature using the public key linked to the original SCITT deployment receipt16. Consequently, an attacker who intercepts the network traffic, utilizes a load balancer to replay an old status message, or attempts a man-in-the-middle attack will fail the signature verification. The observer knows not just that a server is reachable, but that the authorized server is actively generating fresh, valid state data specifically for that request.

16. No Published Incident Is Not Verified Absence

A critical failure in traditional public status dashboards is the assumption that the absence of a red light implies a green light. In legacy systems, if a server crashes completely before it can write an error log or trigger an alert, the dashboard remains oblivious, showing no incident. This results in silent, catastrophic failure. Patefacere eradicates this vulnerability by utilizing the SCITT architecture's append-only ledger combined with continuous external temporal anchoring11. Evidence of health is not the absence of error logs; it is the continuous, uninterrupted stream of signed statements. If Patefacere goes offline, the flow of receipts stops immediately. Therefore, "Verified Absence" of an incident requires positive cryptographic proof: the continuous presence of valid, timestamped health attestations anchored to an external consensus ledger (like Bitcoin via OpenTimestamps). If an auditor examines the timeline and observes a gap in the SCITT sequence numbers or missing temporal anchors, an incident has occurred, regardless of whether a human operator published an incident report. The architecture makes covering up downtime or engaging in retroactive log doctoring mathematically impossible11.

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

The fundamental mandate of Patefacere is to prove operational truth without violating privacy. A common, flawed approach to transparency is the publication of live transactional volumes—such as the number of citizens processed, passport credentials issued, or applications registered. These are business data points. Exposing them can lead to data leakage, sophisticated traffic analysis attacks, and severe violations of privacy laws. Instead, Patefacere proves its integrity entirely through systemic metadata. It can publicly and cryptographically prove:

• The exact SHA-256 hash of the code currently running in production.
• That the code was built by a specific, trusted CI/CD pipeline without human interference.
• That the active memory enclave matches the expected binary signature.
• That the system is actively processing data according to authorized route configurations.
• That data custody transition events are occurring securely, with encrypted backups matching expected volume structures.

By strictly separating the control plane (infrastructure and code integrity) from the data plane (citizen data payloads), Patefacere allows any citizen, journalist, or auditor to verify that the machine processing their data is untampered and operating within legal bounds, without ever needing access to the data of other citizens. This achieves maximum operational transparency with zero privacy compromise.

18. Forty FAQs

19. Twenty-Five Direct Answers

20. 70-Term Glossary

21. Primary-Source Bibliography

• Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., Lasker, S. "An Architecture for Trustworthy and Transparent Digital Supply Chains." RFC 9943, Internet Engineering Task Force (IETF), June 2026\.1.
• Backman, A., Richer, J., Sporny, M. "HTTP Message Signatures." RFC 9421, IETF.6.
• "Supply chain Levels for Software Artifacts (SLSA) Provenance Specification v1.0." SLSA.dev.2.
• "in-toto Attestation Framework Specification v1.0." in-toto.io.15.
• Fassbender, J. "Bitcoin-Anchored Temporal Proof for Transparency Services." draft-fassbender-scitt-time-anchor-03.11.
• Illinois General Assembly. "Illinois Local Records Act." 50 ILCS 205\.8.
• Polli, R. "Digest Fields." RFC 9530, IETF.17.
• Hardt, D. "Signature-Key Header for HTTP Message Signatures." draft-hardt-httpbis-signature-key-04.33.
• Mih, A., Sokolov, D. "Canonical Payload Binding: A Signed Statement Construction Profile." draft-mih-sokolov-scitt-payload-binding-00, July 2026\.23.

Works cited

1. RFC 9943 \- An Architecture for Trustworthy and Transparent Digital Supply Chains \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9943/

2. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0-rc1/provenance

3. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0/provenance

4. In-toto Attestations in Secure Pipelines \- Emergent Mind, https://www.emergentmind.com/topics/in-toto-attestations

5. in-toto attestations \- Trustification, https://trustification.io/blog/2023/03/13/in-toto-attestations/

6. RFC 9421 \- HTTP Message Signatures \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9421

7. Understanding HTTP Message Signatures \- Blog Notes, https://blog.vitalvas.com/post/2025/12/12/understanding-http-message-signatures/

8. Records Inventory and Disposal \- Cook County, https://www.cookcountyil.gov/service/records-inventory-and-disposal

9. 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

10. Guide to Illinois Privacy Laws & Cybersecurity Best Practices \- ConsultNet INC, https://www.consultnetinc.com/guide-to-illinois-privacy-laws-cybersecurity-best-practices

11. Proposal: External Temporal Anchoring Profile for Transparency Services \#460 \- GitHub, https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/460

12. RFC 9943 \- An Architecture for Trustworthy and Transparent Digital Supply Chains, https://datatracker.ietf.org/doc/html/rfc9943

13. Certified Amnesia: A Decision-Evidence Protocol for Provable Context Exclusion in AI Agents \- ResearchGate, https://www.researchgate.net/publication/410951333\_Certified\_Amnesia\_A\_Decision-Evidence\_Protocol\_for\_Provable\_Context\_Exclusion\_in\_AI\_Agents

14. Redefine Trust with Web Bot Authentication \- Akamai, https://www.akamai.com/blog/security/redefine-trust-web-bot-authentication

15. envelope.md \- in-toto/attestation \- GitHub, https://github.com/in-toto/attestation/blob/main/spec/v1/envelope.md

16. HTTP Request Signatures \- SANS Internet Storm Center, https://isc.sans.edu/diary/32266

17. HTTP Patched Digest \- GitHub Pages, https://lpardue.github.io/patched-digest/draft-pardue-httpbis-patched-digest.html

18. An implementation of RFC 9421, the IETF HTTP Message Signatures standard \- GitHub, https://github.com/pyauth/http-message-signatures

19. A Trust Control Plane for Public Trust Infrastructure (PTI) \- Energy Central, https://www.energycentral.com/intelligent-utility/post/a-trust-control-plane-for-public-trust-infrastructure-pti-t4Li00S02OlbhOu

20. HTTP Message Signatures \- RFC 9421 Guide, https://openlinksw.com/data/html/http-signatures-infographic.html

21. Records Management and Retention Policy | Chicago Public Schools, https://www.cps.edu/sites/cps-policy-rules/policies/200/203/203-2/

22. EMILIA in the IETF landscape — a complement, not a competitor, https://www.emiliaprotocol.ai/standards

23. draft-mih-sokolov-scitt-payload-binding-00 \- Canonical Payload Binding: A Signed Statement Construction Profile \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-mih-sokolov-scitt-payload-binding/00/

24. CEP 27 \- Standardizing a publish attestation for the conda ecosystem, https://conda.org/learn/ceps/cep-0027/

25. Chicago Open Data Portal: Government Transparency and Datasets, https://chicagometroauthority.com/chicago-open-data-portal/

26. SCITT: Supply Chain Integrity, Transparency and Trust \- Conserver.io, https://www.conserver.io/deep-dives/scitt-supply-chain-integrity-transparency-and-trust

27. attestation/spec/v1/statement.md at main · in-toto/attestation \- GitHub, https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md

28. History for rfc9421 \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9421/history/

29. draft-ietf-scitt-architecture-11, https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-11

30. Telephone: City: Cicero Zip: 60804 E-mail- required Date Name of Municipality, https://thetownofcicero.com/wp-content/uploads/2025/04/FY-2020-TIF-3.pdf

31. Attestation format | Xygeni User Guides, https://docs.xygeni.io/xygeni-products/build-security/attestation-format

32. Supply Chain Integrity, Transparency, and Trust (scitt) \- IETF Datatracker, https://datatracker.ietf.org/wg/scitt/

33. HTTP Signature Keys \- IETF, https://www.ietf.org/archive/id/draft-hardt-httpbis-signature-key-04.html