Optional event-level provenance / tamper-evidence for CDEvents (worked example)

[MarkovianProtocol]

CDEvents increasingly feed supply-chain decisions (SLSA gates, release approval, audit), but a CDEvent is only as trustworthy as the store it sits in: the same key can re-sign, and a server-side log can be rewritten after the fact. CloudEvents left data integrity to extensions (integrity issues #143 and #565 were closed as out of core scope), so there is a clean seam at the CDEvents layer.

Here is a small, working example of one additive way to close it. The CDEvent carries two optional CloudEvents extension attributes:

• markovianroot: the RFC 8785 (JCS) SHA-256 root of the event's data, committed to an append-only, Bitcoin-anchored log;
• markovianverify: a public endpoint that confirms that root, no account, no key.

A consumer recomputes the root from data and checks it against Bitcoin block headers. It proves the event existed at a point in time and was not altered, attested by a party the operator does not control. It does not assert the build or artifact is correct; that stays a separate concern (SLSA, in-toto).

Worked, independently verifiable example (a real dev.cdevents.artifact.published event, live on-chain commitment):

{
  "id": "3e4ed1e0-81cd-4f9d-a4ea-c2318cabd8ca",
  "source": "/cd/pipeline/release-build",
  "type": "dev.cdevents.artifact.published.0.2.0",
  "specversion": "1.0",
  "time": "2026-07-03T09:15:00Z",
  "datacontenttype": "application/json",
  "markovianroot": "919f2566d52d49a618868a970f3f98eb0bf630ad02c81ca6ed5432e377f03fbf",
  "markovianverify": "https://api.quantsynth.net/verify/919f2566d52d49a618868a970f3f98eb0bf630ad02c81ca6ed5432e377f03fbf",
  "data": {
    "context": { "version": "0.4.1", "id": "6f5817b6-ce9e-49cf-954a-5f10b1ad637b", "source": "/cd/pipeline/release-build", "type": "dev.cdevents.artifact.published.0.2.0", "timestamp": "2026-07-03T09:15:00Z" },
    "subject": { "id": "pkg:oci/example-service@sha256:5b0e...c14a", "source": "/cd/pipeline/release-build", "type": "artifact", "content": { "user": "ci-runner", "sbom": { "uri": "https://artifacts.example.com/example-service/sbom.spdx.json" } } }
  }
}

Verify it yourself: RFC 8785-canonicalize the data, sha256 it, and confirm it equals the data_hash returned at the markovianverify URL (returns verified: true, committed at block 140129). No calendar, no issuer, no trust in the emitting pipeline.

Two honest notes: it is additive and optional (nothing in the core CDEvent changes), and I am not proposing it as a requirement, just showing a working shape in case event-level tamper-evidence is on the roadmap for the SLSA/audit users. Happy to adapt the attribute names or format to CDEvents conventions, or move this to a Discussion if that is the better venue. A runnable stamp-and-verify script is available if useful.

[xibz]

CloudEvents just merged DSSE signatures,. We just need our SDKs to support those, and that should satisfy your concerns. We do not want to leak validation in the actual events. That's conflating boundaries, but using the new DSSE signatures, should accomplish what you are looking to do.

See cloudevents/spec@95514c4

If you have any other questions, we can close this, and open new issues to implement this in the SDKs

[afrittoli]

Thanks @xibz, that's great news!!
Should we add something to the spec, or a separate markdown file, to guide CDEvents users towards DSSE signatures?

[xibz]

@afrittoli - Yes, I think that's the next steps. I was planning on creating the appropriate SDK implementations needed once CloudEvents finishes theirs. Java is in the works right now.

But I think you make a fair call out. Rather than trying to bundle this is a single unit of work, I can provide guidance somewhere in the spec. Let me create a separate issue for that.

[MarkovianProtocol]

Thanks, and DSSE is the right call for the signing half. One boundary worth drawing cleanly, because it is easy to conflate and it matters for the SLSA/audit users:

DSSE proves who signed (authenticity of the bytes under a key). It does not, on its own, prove when the event existed on a log the emitter cannot rewrite. The same key can re-sign, and a producer can rewrite or backdate its own signed store; the signature verifies but says nothing about existence-in-time or non-equivocation against an external record. For "prove this artifact.published existed at T and was not inserted or altered after the fact," you need an anchor outside the producer, which is orthogonal to signing.

So the two compose rather than compete: DSSE for authenticity, an external timestamp/anchor for existence-in-time. On your "don't leak validation into the event" point, agreed, and that is exactly the shape here: the attributes are a pointer (a root plus a public verify URL), not validation logic. Verification happens entirely outside the event, the same boundary as dataref.

Totally fine to keep #315 scoped to DSSE and track the anchor separately, or close it. Mostly wanted the who-vs-when distinction on record for whatever spec guidance you write, since a reader who assumes "signed == tamper-evident-in-time" will be surprised in an audit. Happy to contribute a short note on the two threat models if useful.

[xibz]

Thanks @MarkovianProtocol for making that distinction.

The DSSE RFC in CloudEvents covers authenticity and integrity: who signed it, and whether the signed payload was altered after signing. The existence-in-time / external anchoring concern seems like a separate threat model, so I agree it may be worth tracking separately or documenting as explicit guidance.

My initial thought is that this may not be a specification concern so much as an infrastructure concern. We can certainly provide guidance around external anchoring and transparency logs, but I’m not yet convinced that the CDEvents specification itself should prescribe how those guarantees are achieved. Curious to hear your thoughts.

[MarkovianProtocol]

Completely agree, and that is the right call: the spec should stay mechanism-agnostic and not prescribe how existence-in-time is achieved. Prescribing a specific anchor would be the wrong move for the same reason you would avoid prescribing a specific signing backend.

Where I think there is a small, genuinely useful docs addition, vendor-neutral by construction: a short note that (a) names the threat model explicitly, so a reader does not assume "DSSE-signed == tamper-evident-in-time," and (b) points to the class of mitigations without endorsing one. That class is external timestamping / transparency logs / anchoring: RFC 3161 timestamp authorities, transparency logs (e.g. Rekor), and blockchain anchoring (e.g. OpenTimestamps) all fill the same gap with different trust assumptions. A CDEvents consumer building an audit or SLSA story then knows the distinction exists and where to look, and picks the mechanism that fits their trust model.

Happy to draft that as a short paragraph for whatever venue you prefer (a Security Considerations note, or the DSSE guidance doc @afrittoli mentioned), written neutrally with the mechanism menu rather than a single recommendation. The worked example I posted is just one point on that menu (Bitcoin anchoring), not the thing I would want the spec to name.

[xibz]

That sounds like the right approach to me.

If you’re willing to draft that, I’d be happy to review it with the group during the SIG.

[MarkovianProtocol]

Happy to. Here's a first-pass draft, written vendor-neutral and mechanism-agnostic so the SIG can shape it however fits — it names the threat model, then presents the class of mitigations as a menu rather than a recommendation.

Security consideration: authenticity vs. existence-in-time

Signing answers "who", not "when". DSSE signatures establish authenticity and integrity: which key signed an event, and whether the bytes were altered afterward. Consumers building audit or SLSA stories should note a distinct property signatures do not provide: existence-in-time (non-equivocation). A signature does not prove when an event existed, nor that the producer showed everyone the same event — the key can re-sign, and a producer can rewrite, reorder, or backdate its own store.

When it matters: wherever a CDEvent feeds a decision that could be disputed later — a release gate, a provenance chain, a compliance record. If an operator controls the store, an auditor cannot tell an event recorded at the time from one written in afterward. Closing that gap needs an anchor outside the producer's control.

The mitigation class (mechanism-agnostic): RFC 3161 timestamp authorities (trust the TSA); transparency logs such as Sigstore Rekor (trust the log and its monitors); blockchain anchoring such as OpenTimestamps (trust the chain, no third party at verify time). Each takes a hash over a canonical serialization and returns evidence that the hash existed at or before a point in time. None require putting verification logic inside the event — the event carries at most a small pointer.

Recommendation: where existence-in-time is required, pair signing with one external anchor from the class above; where it is not, DSSE alone is appropriate. The choice of mechanism is deployment infrastructure, not a specification concern.

Shape it however the group prefers — venue (a Security Considerations section vs a standalone guidance doc), wording, and which mechanisms to list are all yours. Happy to join the SIG discussion if that is useful.

[MarkovianProtocol]

Happy to draft it. A separate markdown guide referenced from the spec is probably the cleaner home, so the core spec stays transport-agnostic. I'd structure it in two parts:

1. Authenticity and integrity, via DSSE. Sign the CDEvent (or its CloudEvents envelope) with a DSSE envelope: who emitted it, and whether the payload was altered. This reuses the CloudEvents DSSE work directly.

2. Existence over time, which DSSE doesn't cover. A signature proves who and whether-tampered, not when an event existed or that a record wasn't quietly reissued. An optional commitment to the event's canonical hash, anchored to an external timeline, gives a verifiable "this event existed by time T" that any party can check without trusting the emitter's clock or key custody.

Part 2 is opt-in and anchor-agnostic: the hash is just the event digest, and where it's anchored is an implementation choice. I'll keep it worked-example driven and open a PR for the SIG to review. Sound right?

[MarkovianProtocol]

Drafted the companion guide plus a runnable, no-stubs worked example: https://github.com/MarkovianProtocol/cdevents-provenance (event-provenance.md is the guide; example/ self-verifies with verify_example.py).

It is a separate markdown document and changes nothing in the core schema. Part 1 shows how to wrap a CDEvent in a DSSE envelope for authenticity and integrity (who emitted it, whether the payload was altered), reusing the same DSSE primitive as in-toto/SLSA and compatible with the CloudEvents message-signature discussion in cloudevents/spec#565. Part 2 is an optional, opt-in commitment to the event's RFC 8785 (JCS) SHA-256 canonical hash, anchored to an external timeline, which adds the one property a signature cannot give: verifiable existence-over-time that holds without trusting the emitter's clock or its continued custody of a signing key. Part 2 is deliberately anchor-agnostic (RFC 3161 timestamp, transparency log, or blockchain are all valid; the choice is the implementer's), so CDEvents takes no dependency on any specific anchor or vendor.

The guide includes a "when to use which" table and the worked example: a real dev.cdevents.artifact.published event validated against the v0.5.1 schema, its DSSE envelope, its canonical-hash commitment, and a verifier that shows a genuine event passing both checks and a tampered event failing both.

Happy to open a PR into cdevents/spec in whatever location and format the group prefers, and to walk through it at the SIG.

[xibz]

Happy to open a PR into cdevents/spec in whatever location and format the group prefers, and to walk through it at the SIG.

@MarkovianProtocol - Please do! That would be very helpful!