T3. No extension point for external proof/envelope layers (section 7)
Even if the TC considers signing and verification out of scope for this specification - a defensible scoping decision - the schema currently offers no defined attachment point for external authenticity layers.
There is no reserved proof member, and no statement of envelope compatibility (for example, that a DataProvenance instance MAY be carried as the payload of a W3C Verifiable Credential 2.0, JOSE, or COSE signed envelope).
Without such a hook, implementers who need verifiable provenance must wrap or extend the schema in ad-hoc,
non-interoperable ways.
Suggested resolution:
(a) add a statement that DataProvenance instances MAY be enveloped by external signing mechanisms, with the JSON member ordering / canonicalization considerations this implies; and/or (b) reserve an optional member (or explicitly permit foreign members) so that proof material or proof references can be attached without forking the schema.
This would let the metadata vocabulary defined here compose cleanly with existing and future verifiability standards, rather than competing with them.
Part of CSDPR01 feedback from Yoshi Aoki (yoshi@1o1.co.jp) received 2026-06-11 documnented in full in issue # 167
T3. No extension point for external proof/envelope layers (section 7)
Even if the TC considers signing and verification out of scope for this specification - a defensible scoping decision - the schema currently offers no defined attachment point for external authenticity layers.
There is no reserved proof member, and no statement of envelope compatibility (for example, that a DataProvenance instance MAY be carried as the payload of a W3C Verifiable Credential 2.0, JOSE, or COSE signed envelope).
Without such a hook, implementers who need verifiable provenance must wrap or extend the schema in ad-hoc,
non-interoperable ways.
Suggested resolution: