Problem
recordweb/rwc#7 defines the Issued Copy conceptually. RWP needs to define the
technical operation that produces one from a finalized Record snapshot.
Proposal
Define EXPORT_ISSUED_COPY as a defined operation (not a new state
transition — the underlying Record's state is unaffected) that a RWP-node
performs on request, producing a self-contained artifact.
Proposed operation contract
Input: a Record identified by did:rwp, at a specific snapshotHash,
which must be in finalized state and must carry at least one valid proof (#7).
Output: an Issued Copy artifact containing:
{
"issuedCopyOf": "did:rwp:parlament.ch/records/frage-bernasconi-hs2026",
"snapshotHash": "sha256-...",
"payload": { "...": "the finalized snapshot's payload, unchanged" },
"proof": [ "...as carried by the source Record (RWP-1)..." ],
"issuedAt": "2026-07-23T08:00:00Z",
"issuedTo": "optional: DID or identifier of the addressee, if bound"
}
Properties:
- The artifact is immutable once issued; re-running the export for the same
snapshot and addressee is idempotent and yields byte-identical output.
- The artifact does not require the issuing RWP-node to be reachable for
verification — verification requires only the proof's public key
material (resolvable via the verificationMethod DID) and the artifact
itself.
- The export operation is logged as an event within the issuing system
(out of scope for RWP to standardize the log format, but the fact of
export should be attributable, e.g. for audit purposes).
Open questions for CG discussion
- Should
issuedTo be mandatory (binding the copy to a specific addressee,
preventing redistribution) or optional (bearer-style artifact)?
- Does the export operation itself need to be a documented, provenance-linked
act within RecordWeb (comparable to finalization in Section 5.4 of RWC),
or is it purely an implementation-system concern?
Problem
recordweb/rwc#7 defines the Issued Copy conceptually. RWP needs to define the
technical operation that produces one from a finalized Record snapshot.
Proposal
Define
EXPORT_ISSUED_COPYas a defined operation (not a new statetransition — the underlying Record's state is unaffected) that a RWP-node
performs on request, producing a self-contained artifact.
Proposed operation contract
Input: a Record identified by
did:rwp, at a specificsnapshotHash,which must be in
finalizedstate and must carry at least one validproof(#7).Output: an Issued Copy artifact containing:
{ "issuedCopyOf": "did:rwp:parlament.ch/records/frage-bernasconi-hs2026", "snapshotHash": "sha256-...", "payload": { "...": "the finalized snapshot's payload, unchanged" }, "proof": [ "...as carried by the source Record (RWP-1)..." ], "issuedAt": "2026-07-23T08:00:00Z", "issuedTo": "optional: DID or identifier of the addressee, if bound" }Properties:
snapshot and addressee is idempotent and yields byte-identical output.
verification — verification requires only the
proof's public keymaterial (resolvable via the
verificationMethodDID) and the artifactitself.
(out of scope for RWP to standardize the log format, but the fact of
export should be attributable, e.g. for audit purposes).
Open questions for CG discussion
issuedTobe mandatory (binding the copy to a specific addressee,preventing redistribution) or optional (bearer-style artifact)?
act within RecordWeb (comparable to finalization in Section 5.4 of RWC),
or is it purely an implementation-system concern?