Standards Alignment
Implemented cryptographic primitives in the current receipt path, compatibility layers, and future interoperability targets.
WitnessOps separates implemented receipt primitives from standards used by compatibility, retained, or future export lanes. A standard named in architecture documentation is not automatically present in every receipt or checked by every verifier.
1. Current legacy receipt-profile primitives
The current canonical public_exposure_review receipt contract uses:
| Primitive | Contract use | Public /verify behavior |
|---|---|---|
| JSON receipt profile | witnessops.receipt.v0 plus witnessops.verification_context.v1 | Exact envelope and profile structure checked |
| SHA-256 | Declared evidence-manifest digest and producer artifact hashing | Digest syntax checked; manifest and artifact bytes not recomputed |
| Ed25519 | Receipt signature algorithm | Signature-block syntax checked; cryptographic signature and production signer authorization not checked |
| RFC 3339 UTC | Observation, performance, issuance, and optional expiry timestamps | Syntax and chronology checked; no independent time authority supplied |
This receipt is not documented as universally DSSE-wrapped, RFC 3161-timestamped, in-toto-encoded, transparency-logged, or SLSA-provenanced.
2. Status of named standards
| Layer | Current status | Safe interpretation |
|---|---|---|
| Ed25519 | Implemented in receipt signature contracts and internal verifier paths | A signature becomes meaningful only when checked against an authentic, policy-authorized key |
| SHA-256 | Implemented for manifest and artifact integrity contracts | Receipt-only syntax does not prove matching bytes |
| RFC 3339 | Implemented timestamp format | Issuer timestamps are not independent trusted time |
| DSSE | Design or compatibility envelope unless a specific emitted artifact and verifier path are named | Do not claim every receipt is DSSE-wrapped |
| RFC 3161 | Compatibility or optional proof layer where token and chain artifacts are present | Full time proof requires token, imprint, TSA chain, and policy verification |
| in-toto | Export/alignment target unless a specific statement is emitted | Do not infer it from receipt fields |
| SLSA | Build-provenance alignment target | Not a core public_exposure_review receipt primitive |
| SCITT | Future transparency interoperability target | Not required for current local receipt validation |
3. Why the layers remain separate
Each layer answers a different question:
- signature: do these bytes match a particular private key?
- key policy: was that key authorized for this workflow, environment, usage, and time?
- artifact hashing: do supplied files match the manifest?
- timestamp authority: did an independently trusted time source cover the signed object?
- attestation format: how is claim meaning represented for other tooling?
- transparency: was a statement committed to an externally inspectable log?
Combining those questions into “the receipt is signed” hides missing inputs. WitnessOps results report checks separately and preserve indeterminate when a required layer was not independently completed.
4. Production key policy
Ed25519 signature syntax alone does not establish a trusted production signer. Production acceptance for the legacy public_exposure_review profile requires an active, revision-pinned registry policy, an allowlisted production key with required usage, validity and revocation checks, and recorded custody approval.
The current policy and registry snapshot are draft and authorize no production key. The public receipt adapter therefore does not claim cryptographic or production signer verification.
5. Verifier guidance
Choose a verifier path that implements the exact declared profile:
- use
/verifyfor bounded supported receipt JSON only - use the internal full-package verifier when the complete package and independently selected trust inputs are available
- use standard-specific tooling only when the package actually contains the corresponding DSSE, RFC 3161, in-toto, SLSA, or transparency artifacts
The canonical full verifier is currently internal and has no supported public distribution. Public /verify does not become a package verifier by accepting caller-supplied trust or evidence; it rejects those companion inputs.
6. Next-page handoff
Read Verification for the current surface boundary and Receipt Specification for exact product fields.