Re: FW: VC-if-eye a plain old .JPG file [was: Binding credentials to publicly accessible repositories]

Michael,
Thank you — useful prior art, and it confirms that embedding VCs in
non-document artifacts is tractable. The XMP/EXIF approach works well for
file-level attestation of binary media.

The source code case has two properties that make it worth asking the
question more carefully:


   - First, the granularity is sub-file. The provenance claim attaches to a
   specific function, not to the file as a whole. A file may contain dozens of
   functions with different provenance categories — some verified, some
   pattern-derived, some WAGs. File-level attestation doesn't help here.
   - Second, source code undergoes transformations that binary media does
   not — reformatting, refactoring, minification, transpilation. A metadata
   field stripped by a formatter is silently lost. The docstring survives most
   of these transformations because it is semantically part of the code. An
   external or header-based embedding may not.

So the question I'm really asking is not "can a VC be embedded in a source
file" — clearly it can, your 2021 example shows one approach and mine shows
another. The question is: given the sub-file granularity requirement and
the transformation-survival requirement, is the docstring Provenance
section the right mechanism? Are there alternatives that handle these
requirements better? And are there fragilities in my approach that I
haven't considered — the AST normalization question being the obvious one —
and noting that while Python has a single reference parser with a stable
AST grammar, the same approach faces significant complications in other
languages: JavaScript has multiple competing parsers; C++ preprocessing
happens before parsing so semantically identical functions may have
different ASTs depending on macro expansion; Erlang's pattern matching and
guard syntax have no straightforward cross-language AST equivalent. A
language-agnostic solution to the subject identification problem may need a
different approach entirely, or a per-language normalization specification
as part of the content type convention.

bob wyman

On Tue, Mar 31, 2026 at 11:39 PM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> Here’s something from 2021…what do you see as the challenge with embedded
> a VC in any document? E.g. code, Word doc, XML purchase order, a photo?
>
>
>
> *From:* Michael Herman (Trusted Digital Web)
> *Sent:* Sunday, August 8, 2021 11:48 PM
> *To:* Leonard Rosenthol <lrosenth@adobe.com>; public-credentials@w3.org
> *Subject:* VC-if-eye a plain old .JPG file [was: Binding credentials to
> publicly accessible repositories]
>
>
>
> RE: There is no mechanism in XMP nor in most standard asset formats for
> establishing a model for tamper evidence, such as Digital Signatures,
> (H)MAC, etc
>
>
>
> Leonard here’s a counterexample.
>
>
>
> I’ve applied to the principles and data model for Structured Credentials (
> https://www.youtube.com/watch?v=FFv4WZ0p3aY&list=PLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD&index=1)
> to VC-if-eye a plain old .JPG file (a photo I took with my Pixel 4a phone).
>
>
>
>    - Test1_original.jpg is the original, unmodified test copy of the photo
>    - Test1_ps1.txt is a script that uses exiftool.exe to add the
>    Structured Credential structures to the original test copy of the photo
>    …including the proof elements stored in the EnvelopeSeal structure.  They
>    are stored as elements in the XMP Keyword Info property of the photo.
>    - Test1_xmp.png is a screen shot of the Structured Credential
>    structures embedded into the XMP Keyword Info properties of the photo.
>
>
>
> We now have a mechanism for a .JPG file (or any XMP compatible media file)
> to serve as both a photo and a Verifiable Credential.  We are now able to
> VC-if-eye any XMP compatible media file.
>
>
>
> Any holes?
>
>
>
> Best regards,
>
> Michael Herman
>
> Far Left Self-Sovereignist
>
>
>
> Self-Sovereign Blockchain Architect
>
> Trusted Digital Web
>
> Hyperonomy Digital Identity Lab
>
> Parallelspace Corporation
>
>
>
>
>
>
>
>
>
> *From:* Leonard Rosenthol <lrosenth@adobe.com>
> *Sent:* August 3, 2021 3:02 PM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>;
> public-credentials@w3.org
> *Subject:* Re: Binding credentials to publicly accessible repositories
>
>
>
> There is no mechanism in XMP nor in most standard asset formats for
> establishing a model for tamper evidence, such as Digital Signatures,
> (H)MAC, etc.
>
>
>
> Leonard
>
>
>
> *From: *Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Date: *Tuesday, August 3, 2021 at 2:49 PM
> *To: *public-credentials@w3.org <public-credentials@w3.org>, Leonard
> Rosenthol <lrosenth@adobe.com>
> *Subject: *Re: Binding credentials to publicly accessible repositories
>
> Leonard, how do you define "native tamper-evident system"?
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
>
>
> ------------------------------
>
> *From:* Leonard Rosenthol <lrosenth@adobe.com>
> *Sent:* Tuesday, August 3, 2021 10:53:47 AM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>;
> public-credentials@w3.org <public-credentials@w3.org>
> *Subject:* Re: Binding credentials to publicly accessible repositories
>
>
>
> Michael, thanks for the reference to XMP…but you are probably not aware
> that I am the chair of ISO TC 171/SC 2/WG 12 where XMP is standardized *
> *and** the project leader for XMP itself.   (oh, and I am also the XMP
> Architect internally to Adobe 😉 ).
>
>
>
> So yes, leveraging existing open standards such as XMP is indeed a key to
> delivering on the promises mentioned below – but it can’t be the only
> solution due to it being a text-based serialization (thus not lending
> itself well to binary data structures) and not having a native
> tamper-evident system.  Additionally, while it is supported by most common
> asset formats, it is not supported by all.
>
>
>
> Leonard
>
>
>
> *From: *Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Date: *Tuesday, August 3, 2021 at 10:43 AM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>, public-credentials@w3.org <
> public-credentials@w3.org>
> *Subject: *Re: Binding credentials to publicly accessible repositories
>
> Checkout https://en.wikipedia.org/wiki/Extensible_Metadata_Platform
>
>
>
> And here's a data model to consider for use in a custom XMP profile:
> https://youtu.be/FFv4WZ0p3aY
>
>
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------
>
> *From:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Sent:* Friday, July 30, 2021 1:25:18 PM
> *To:* Leonard Rosenthol <lrosenth@adobe.com>; public-credentials@w3.org <
> public-credentials@w3.org>
> *Subject:* RE: Binding credentials to publicly accessible repositories
>
>
>
> So an alternate strategy to avoid embed an actual VC or otherwise try to
> attach a VC to an asset is to use the metadata capabilities of each of
> these formats to store the credential id, @context, vc type list,
> credentialSubject id, the individual claims (name-value pairs), and the
> proof elements
>
>
>
> …vc-if-eye each format using each format’s native metadata capabilities.
>
>
>
> *From:* Leonard Rosenthol <lrosenth@adobe.com>
> *Sent:* July 30, 2021 1:03 PM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>;
> public-credentials@w3.org
> *Subject:* Re: Binding credentials to publicly accessible repositories
>
>
>
> Michael – not sure you understand the scenario here.
>
>
>
> We aren’t building a specific system/solution for our own needs and those
> of our customers – we are developing an open standard that associates
> provenance with existing assets (eg. JPEG, PNG, MP4, PDF, etc.).  Since
> those are the formats that are recognized by systems (and regulatory
> solutions) today, it would make no sense to start wrapping them in some
> other format (be it JSON, XML, or whatever).  JPEG files (for example) need
> to work everywhere they do today – BUT contain tamper-evident provenance.
>
>
>
> Leonard
>
>
>
> *From: *Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Date: *Friday, July 30, 2021 at 2:46 PM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>, public-credentials@w3.org <
> public-credentials@w3.org>
> *Subject: *RE: Binding credentials to publicly accessible repositories
>
> It’s a SMOP (small matter of programming).  Once upon a time, browers
> weren’t capable of displaying a lot of different kinds of resources (e.g.
> XML).
>
>
>
> Why not render your VCs as XML?
>
> …or consider using server-side rendering?
>
> …or write an in-browser renderer using WASM?
>
>
>
> *“The difficult we can do, the impossible takes us a little bit longer…” *
> 😊
>
>
>
> *From:* Leonard Rosenthol <lrosenth@adobe.com>
> *Sent:* July 30, 2021 12:35 PM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>;
> public-credentials@w3.org
> *Subject:* Re: Binding credentials to publicly accessible repositories
>
>
>
> Given that putting a “.vc” file on a website or in a Twitter feed of
> YouTube channel isn’t going have it properly displayed – that’s not an
> option, unfortunately, Michael.
>
>
>
> Leonard
>
>
>
> *From: *Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Date: *Friday, July 30, 2021 at 1:05 PM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>, public-credentials@w3.org <
> public-credentials@w3.org>
> *Subject: *RE: Binding credentials to publicly accessible repositories
>
> I suggest storing the “original version” of the artwork as a claim within
> a signed credential …the credential wraps the artwork like a container or a
> “frame”.
>
>
>
> I believe this is much better than trying to attach a credential to the
> artwork.
>
>
>
> Best regards,
>
> Michael Herman
>
> Far Left Self-Sovereignist
>
>
>
> Self-Sovereign Blockchain Architect
>
> Trusted Digital Web
>
> Hyperonomy Digital Identity Lab
>
> Parallelspace Corporation
>
>
>
>
>
>
>
>
>
> *From:* Leonard Rosenthol <lrosenth@adobe.com>
> *Sent:* July 30, 2021 10:31 AM
> *To:* public-credentials@w3.org
> *Subject:* Binding credentials to publicly accessible repositories
>
>
>
> I realize that I might be out on the bleeding edge a bit, though not
> completely as I think it is very similar to what OpenBadges will face as
> they move to VC’s…
>
>
>
> In the Trust Model section of the VC Data Model spec, it states that one
> of aspects of that model is:
>
> The holder trusts the repository to store credentials securely, to not
> release them to anyone other than the holder, and to not corrupt or lose
> them while they are in its care.
>
> This is certainly true when the repository in question is something like a
> wallet that is designed to be kept private or local (not shared).  But what
> happens when the repository is designed to be out in the public… such as an
> image or PDF with the VC embedded?
>
>
>
>
>
> As part of the C2PA’s (https://c2pa.org) work on establishing provenance
> for digital assets, we will be using VC’s as a way for persons and
> organizations to establish their relationships to the asset.  Specifically
> in this instance, we’re extending schema.org’s Person and Organization
> schemas, as used by their CreativeWork schema, to support referencing a
> VC.  This then allows the author or publisher (or any of the other roles in
> CW) to provide their credentials in that role, which (a) adds useful trust
> signal(s) to the end consumer and (b) helps establish reputation.
>
>
>
> These VC’s (etc.) will be embedded into the assets (e.g., video, images,
> documents, etc.) in a tamper-evident manner, so that in addition to the
> individual VC’s “proof”, any attempt to change the CreativeWork
> relationships, etc. can also be detected.   This all works great.
>
>
>
> However, in doing some threat modelling, we recognized that we have no
> protection against a malicious actor simply copying the VC from one asset
> and dropping it into another (and then signing the new setup), because
> there is nothing that binds the credential to the asset in our case.
>
>
>
> Has anyone run into this scenario before and has some guidance to offer?
> Am I doing something that I shouldn’t be doing – and if so, what does that
> mean for OpenBadges?
>
>
>
> All thoughts and suggestions welcome!
>
>
>
> Thanks,
>
> Leonard
>
>
>