Standards Alignment

WitnessOps uses open standards for the cryptographic envelope, trusted time, and attestation layers. Some internal packaging and ledger formats remain custom, documented, and intentionally non-standard.

The Principle

Standardize signature first, then time, then meaning, then ecosystem export.

This is the frozen priority order. Each standard solves one problem cleanly, and they compose in sequence:

Why This Order

DSSE first because it solves the most dangerous ambiguity: "what exactly was signed?" Without DSSE, a signed blob could be interpreted as multiple payload types. DSSE binds the payload type and exact bytes into the signature. Every other standard builds on this.

RFC 3161 second because trusted time is the biggest external-verification upgrade after signature clarity. A self-asserted timestamp from the issuer proves nothing to a skeptic. An RFC 3161 token from an independent timestamp authority proves the signed object existed before a specific time — and can be verified offline with the token and TSA chain alone.

in-toto third because it standardizes what the claim means. DSSE tells you the bytes are authentic. in-toto tells you the bytes represent a structured statement with a subject, a predicate type, and domain-specific content. This makes WitnessOps claims readable by standard attestation tooling.

SLSA and SCITT later because they are ecosystem interoperability targets, not core proof primitives. SLSA matters when WitnessOps proof bundles need to interoperate with build provenance systems. SCITT matters when receipts need to be registered with external transparency services. Neither is required for local proof construction or offline verification.

What Each Standard Provides

DSSE (Dead Simple Signing Envelope)

• Wraps every signed receipt and claim
• Prevents payload-type confusion attacks
• Payload type: application/vnd.witnessops.execution-receipt.v2+json
• Specification: DSSE v1.0.2

RFC 3161 (Time-Stamp Protocol)

• Timestamps the SHA-256 digest of the DSSE envelope bytes
• Produces a portable, independently verifiable timestamp token
• Token format: DER-encoded TimeStampResponse
• Can be verified with OpenSSL or any RFC 3161-compatible tool
• Specification: RFC 3161

in-toto (Attestation Framework)

• Wraps claims as standard statements with subject, predicate type, and predicate content
• WitnessOps uses custom predicate types for execution receipts, promotions, drift, and rollbacks
• Allows standard attestation tooling to parse WitnessOps claims without WitnessOps-specific code
• Specification: in-toto Attestation Framework v1.0

What Stays Custom

WitnessOps uses custom formats for internal operations that do not need ecosystem interoperability:

• Hash-chained NDJSON ledgers — the internal receipt chain format
• Merkle batch proofs — the internal integrity structure
• Bundle directory layout — the packaging convention

These formats are stable and documented but are not proposed as external standards. Standards are for export. Internal formats are for speed and operational control.

Current Implementation Status

What This Means for Verifiers

A verifier does not need WitnessOps-specific tools. Standard cryptographic libraries can:

• Parse the DSSE envelope and verify the Ed25519 signature
• Verify the RFC 3161 timestamp token against the TSA certificate chain
• Parse the in-toto Statement and inspect the predicate
• Verify the Merkle inclusion proof against the checkpoint

WitnessOps is built to be verified, not to be trusted.