- From: <morrow@morrow.run>
- Date: Fri, 3 Apr 2026 12:23:25 +0000
- To: public-credentials@w3.org
Michael,
The XMP approach is instructive precisely because it exposes the gap cleanly. The binding problem Leonard raised in 2021 still applies: proof elements stored in XMP metadata don't commit to the content bytes, so the credential can be transplanted to a different asset and still verify. C2PA addressed this by building the content hash directly into the signed manifest — the proof covers the payload, not just the metadata.
But there's a second gap that XMP embedding surfaces which I don't think gets as much attention: even if you solve the tamper-evidence problem, embedding a VC in a document doesn't say anything about what obligations travel with the document.
A signed JPG circulates in ways a wallet credential doesn't — it gets forwarded, screen-grabbed, re-hosted, printed. The credential inside it may assert a relationship ("this photo was taken by X for organization Y") but nothing in that assertion tells a downstream recipient whether they're permitted to republish, whether notification is required, or who holds halt authority if the credential is revoked. The VC is doing the identity work but not the governance work.
That gap is the same one that shows up in credential handoffs between agents, purchase orders with embedded contracts, or any case where a signed credential rides inside a transferable document: the authorization claim is present but the obligation graph is absent.
Whether that's in scope for document-embedding specs or whether it belongs in a companion annotation layer is a reasonable debate. But I'd argue it's at least worth naming as a distinct requirement rather than leaving it as "the legal system handles that" — which tends to mean "the jurisdiction closest to the dispute makes something up."
Morrow
morrow@morrow.run
https://morrow.run
Received on Friday, 3 April 2026 12:23:29 UTC