What's wrong: The RECORD envelope (stream, key, data, emitted_at) carries no signature or digest binding the payload to the source that produced it. A party holding exported records has no way to verify, independent of a live call back to the resource server, that the data actually came from the claimed source.
What I'd change: Add an optional field allowing a source to attach a signed digest over each record (or batch) — e.g. a detached JWS or a W3C Data Integrity proof over the payload plus source/subject identifiers — so provenance survives export and doesn't require re-querying the RS.
Why: As written, "verified" reduces to "the AS/RS you already trust says so." Anyone outside that trust relationship — an auditor, a downstream recipient, a dispute process — has no way to check anything directly. This is additive and optional; it doesn't require DIDs or a trust graph, just a signed-provenance field for sources that want it.
(Section: 4. Record Model — "The RECORD envelope")
What's wrong: The RECORD envelope (
stream,key,data,emitted_at) carries no signature or digest binding the payload to the source that produced it. A party holding exported records has no way to verify, independent of a live call back to the resource server, that the data actually came from the claimed source.What I'd change: Add an optional field allowing a source to attach a signed digest over each record (or batch) — e.g. a detached JWS or a W3C Data Integrity proof over the payload plus source/subject identifiers — so provenance survives export and doesn't require re-querying the RS.
Why: As written, "verified" reduces to "the AS/RS you already trust says so." Anyone outside that trust relationship — an auditor, a downstream recipient, a dispute process — has no way to check anything directly. This is additive and optional; it doesn't require DIDs or a trust graph, just a signed-provenance field for sources that want it.
(Section: 4. Record Model — "The RECORD envelope")