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

Here is part of an idea:

For the credentialSubject.id, use a value based on the Locator DID for the function (within a class within a namespace) within a code file. An incomplete example is:

Starting with:
Method: Web7.TrustLibrary.Did.DIDDocumemt.Documenter.Initialize
Found in this code file: https://github.com/Web7Foundation/Web7.TrustLibrary/blob/main/src/Web7.TrustLibrary.Did/DIDDocumenter.cs#L72-L87


…derive…

“id” : “did://github.com/Web7Foundation:Web7.TrustLibrary/blob/main/src/Web7.TrustLibrary.Did/DIDDocumenter.cs?entity=”Web7.TrustLibrary.Did.DIDDocumemt:Documenter:Initialize”#L72-L87<https://github.com/Web7Foundation/Web7.TrustLibrary/blob/main/src/Web7.TrustLibrary.Did/DIDDocumenter.cs#L72-L87>”

(which Chrome is able to correctly resolve to the specific instance of the Initialize method.

NOTE: This id syntax can also be used to name individual namespaces and classes in addition to specific methods.

NOTE: The VC containing this credentialSubject.id can appear anywhere in the code file as a comment block …ideally at the bottom …especially because it is autoresolvable.

…or something like that.

Michael
Web 7.0

From: Bob Wyman <bob@wyman.us>
Sent: Wednesday, April 1, 2026 10:24 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Cc: public-credentials (public-credentials@w3.org) <public-credentials@w3.org>
Subject: Re: FW: VC-if-eye a plain old .JPG file [was: Binding credentials to publicly accessible repositories]


Michael,
The VC data does not need to be part of the AST—and in fact it is undesirable for it to be there. If the VC is in the AST, the subject hash computation becomes circular: the hash of the code includes the hash, which is impossible to compute. It also means that Python’s introspection functions return VC content mixed in with documentation, which is not what either a human reader or a tool expects from inspect.getdoc().

A comment block, not a docstring, is the right approach and is sufficient.

Considering your question has also led to a further refinement: the full provenance record—every VC ever issued about a function, including endorsements, challenges, qualifications, and supersessions—should live in an external registry keyed by the function’s stable identifier. The inline comment block is then a curated subset chosen by the implementor for immediate visibility: typically the primary verification VC and perhaps one or two key endorsements. A reader sees the summary inline; a tool that wants the full picture follows the registry URI. This keeps source files small regardless of how rich the external discourse becomes.

The revised proposal:

def rate_limit_by_ip(parent_values, params, get_state,

                     set_state, publish, service_emit=None):

    """

    Sliding-window rate limiter per client IP address.

    RFC 7033 Section 9.3: servers should rate-limit by IP

    to prevent abuse and email harvesting.

    """

    # @provenance:

    #   registry: https://archive.example.com/provenance/rate-limit-ip-v1


    #   tag: tag:archive.example.com<http://archive.example.com>,2026:rate-limit-ip-v1

    #   @vc:

    #     category: verified

    #     implements: RFC 7033 Section 9.3

    #     verified-by: did:key:z6Mk...

    #     token: eyJhbGciOiJFZERTQSJ9...

    #     subject: ni:///sha-256;a3f8c2d1...?ct=python-ast

The # @provenance: block uses indented YAML structure so that multiple VCs within a single function are unambiguously delimited, and so that VCs referencing other VCs can be represented cleanly. The block is valid YAML once the leading # characters are stripped, making inspect_provenance() straightforward to implement. The triple-quote python convention will not work as an alternative: subsequent triple-quoted strings in a function body appear in the AST as Constant nodes, reintroducing the circular hashing problem.

Multiple authorities can independently attest to the same function by adding their own @vc: blocks—or by publishing to the external registry—without any of them needing to reference or subsume the claims of the others. A developer, a security reviewer, and a third-party auditor each attach independent attestations. This maps naturally onto the proof sets model suggested earlier in this thread.

This also raises a further capability: VCs whose subject is another VC rather than the code itself. The VC Data Model supports this naturally—the credentialSubject.id can be the ni: URI of an existing VC, making it a statement about a statement. This enables endorsement (“I concur with this verification”), challenge (“I dispute this claim—specifically, the sliding window resets on each request rather than sliding”), qualification (“this claim holds under conditions X and Y but not Z”), and supersession (“this VC has been replaced by a corrected version”). The result is a structured discourse about code quality that is cryptographically bound, auditable, and tamper-evident—something closer to how academic citation works, but with verifiable identity and revocability.

bob wyman

On Wed, Apr 1, 2026 at 11:05 AM Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> wrote:
Bob, does the VC data need to become part of the AST or is it sufficient for the VC data to appear as a comment block (e.g. at the end of the code file)?

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Bob Wyman <bob@wyman.us<mailto:bob@wyman.us>>
Sent: Tuesday, March 31, 2026 11:27:36 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Cc: public-credentials (public-credentials@w3.org<mailto:public-credentials@w3.org>) <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: 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<mailto: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<mailto:lrosenth@adobe.com>>; public-credentials@w3.org<mailto: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



[cid:image001.jpg@01DCC1D0.83765180]







From: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Sent: August 3, 2021 3:02 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; public-credentials@w3.org<mailto: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<mailto:mwherman@parallelspace.net>>
Date: Tuesday, August 3, 2021 at 2:49 PM
To: public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto:public-credentials@w3.org>>, Leonard Rosenthol <lrosenth@adobe.com<mailto: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<mailto:lrosenth@adobe.com>>
Sent: Tuesday, August 3, 2021 10:53:47 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto: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<mailto:mwherman@parallelspace.net>>
Date: Tuesday, August 3, 2021 at 10:43 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto: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<mailto:mwherman@parallelspace.net>>
Sent: Friday, July 30, 2021 1:25:18 PM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>; public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto: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<mailto:lrosenth@adobe.com>>
Sent: July 30, 2021 1:03 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; public-credentials@w3.org<mailto: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<mailto:mwherman@parallelspace.net>>
Date: Friday, July 30, 2021 at 2:46 PM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto: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<mailto:lrosenth@adobe.com>>
Sent: July 30, 2021 12:35 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; public-credentials@w3.org<mailto: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<mailto:mwherman@parallelspace.net>>
Date: Friday, July 30, 2021 at 1:05 PM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto: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



[cid:image002.jpg@01DCC1D0.83765180]







From: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Sent: July 30, 2021 10:31 AM
To: public-credentials@w3.org<mailto: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<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<http://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