Standards Alignment
Which open standards WitnessOps uses, in what order, and why.
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.
1. Problem this page solves
Standards pages often collapse two separate questions:
- which standards are used for core proof
- which formats stay custom for internal operations
This page keeps those layers separate and explains the order in which WitnessOps applies standards.
2. What you should understand after reading
After this page, you should understand:
- which standards WitnessOps uses now
- why those standards are applied in a specific order
- what each standard contributes to the proof path
- which internal formats stay custom and why
3. Core 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.
| Priority | Standard | What it solves |
|---|---|---|
| 1 | DSSE v1.0.2 | what exact bytes were signed |
| 2 | RFC 3161 | trusted time over a signed object |
| 3 | in-toto v1.0 | what the signed claim means as a structured attestation |
| 4 | SLSA v1.2 | build provenance and supply-chain assurance |
| 5 | SCITT | interoperable transparency receipts in a future export lane |
4. Why this order exists
DSSE first
DSSE solves the most dangerous ambiguity first: what exactly was signed?
Without DSSE, a signed blob can be interpreted as multiple payload types. DSSE binds both payload type and exact bytes into the signature. Everything else builds on that.
RFC 3161 second
Trusted time is the biggest verification upgrade after signature clarity.
A self-asserted timestamp from the issuer proves very little to a skeptical reviewer. An RFC 3161 token from an independent timestamp authority proves the signed object existed before a specific time and can be checked offline with the token and TSA chain.
in-toto third
in-toto 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, predicate type, and domain-specific content. That makes WitnessOps claims readable by standard attestation tooling.
SLSA and SCITT later
SLSA and SCITT are ecosystem interoperability targets, not core proof primitives.
SLSA matters when WitnessOps bundles need to interoperate with build-provenance systems. SCITT matters when receipts need external transparency registration. Neither is required for local proof construction or offline verification.
5. 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
6. What stays custom
WitnessOps keeps some internal formats custom because they do not need broader ecosystem interoperability:
- hash-chained NDJSON ledgers — internal receipt-chain format
- Merkle batch proofs — internal integrity structure
- bundle directory layout — packaging convention
These formats are stable and documented, but they are not proposed as external standards. Standards are for export. Internal formats are for operational speed and control.
7. Repo-evidenced implementation status
This table separates implementation claims visible in this repository from design targets and export alignment. Do not upgrade “documented” or “aligned” to “implemented” unless the emitting or verifying artifact is linked.
| Layer | Safe status language | Evidence boundary |
|---|---|---|
| Ed25519 local signature | Implemented for the current receipt verifier path. | Receipt schema and verifier code define local signature attestation fields and Ed25519 checks. |
| RFC 3161 fields | Represented in receipt schemas and checked structurally in receipt-first mode. Full token and certificate-chain verification requires the timestamp token, chain, and bundle-complete verifier path. | Receipt JSON can carry timestamp references and message-imprint status; receipt-only mode cannot prove the token bytes or chain by itself. |
| DSSE | Design target or documented envelope unless an emitting/verifying implementation artifact is linked. | This docs pass should not claim every receipt and claim is DSSE-wrapped from this repo alone. |
| in-toto | Export/alignment target unless emitted statement artifacts are linked. | Keep claim meaning separate from signed-envelope verification. |
| SLSA | Alignment target for build-provenance contexts, not a core receipt proof primitive. | Use only where the relevant provenance predicate is emitted and verified. |
| SCITT | Future compatibility target. | Not required for local receipt-first verification. |
8. What this means for verifiers
A verifier should choose the verification path that matches the claim being made.
In public receipt-first mode, the verifier can only make receipt-scoped claims about supported receipt JSON. It cannot prove artifact-byte integrity, bundle completeness, or full timestamp-token validity unless the matching bundle material is present and checked.
In bundle-complete mode, a verifier may use standard cryptographic tooling to check the layers that are actually present, for example:
- verify an Ed25519 signature over the declared signed subject
- verify an RFC 3161 timestamp token against the TSA certificate chain
- parse a DSSE or in-toto artifact when that artifact is included in the bundle
- recompute Merkle or manifest integrity when the referenced artifact bytes are available
WitnessOps is built to be verified, not to be trusted by default.