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

Hidden text sounds like it was designed specifically to make prompt
injection easier.

--------------
Alan Karp


On Thu, Apr 2, 2026 at 9:33 AM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> RE: The right model there is document comments, exactly as Word and
> Google Docs handle tracked changes and annotations: the provenance tags are
> attached to specific passages, separately stored, and toggled visible or
> invisible depending on whether the reader wants to see them.
>
>
>
> For Word documents, Word (and other word processors) have the concept of
> Hidden Text, a text attribute. A VC can be entered as a paragraph within a
> document and then marked as Hidden Text. Refer to:
> https://claude.ai/share/d33d7e29-32eb-4b62-9169-f9aa284eb695
>
>
>
>
>
> Michael Herman
>
> Web 7.0
>
>
>
> *From:* Bob Wyman <bob@wyman.us>
> *Sent:* Thursday, April 2, 2026 8:26 AM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Cc:* Daniel Hardman <daniel.hardman@gmail.com>; 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,
> Your PINC <https://share.google/aimode/mt3UfoPjvqyIg5gY3> is directly
> relevant prior art. The Archive implements the discipline of assembling
> software from a library of verified, interface-conforming components, now
> applying this to LLM-generated code using VCs as the attestation mechanism.
> That the idea was sound in the early 80s and is sound now is reassuring
> rather than surprising.
>
> On multiple implementations of a single interface: yes, exactly. A Form is
> an abstract contract—the definition of the `Sort()` interface you
> suggested—and multiple implementations can conform to it. A Python
> implementation, a Rust implementation, and a Go implementation of the same
> rate-limiting contract are all the same Form with different conforming
> evaluators. Each implementation carries its own content hash and its own
> VC; the Form identity remains stable across all of them.
>
> On “a single file per function”: the annotation model already gives you
> this. The source file contains both the function and its VC comment
> block—one file, function and annotation together. Two artifacts do not need
> to be maintained separately because the annotation lives in the source.
>
> However, the "one file per function" approach becomes cumbersome the
> moment you move beyond programming source code. A legal contract assembled
> from fifty verified clauses does not want fifty separate VC files—nor does
> it want the VC embedded and always visible in the output contract. The
> right model there is document comments, exactly as Word and Google Docs
> handle tracked changes and annotations: the provenance tags are attached to
> specific passages, separately stored, and toggled visible or invisible
> depending on whether the reader wants to see them. The W3C Web Annotation
> standard was designed precisely for this—structured, addressable
> annotations attached to portions of a document without modifying the
> document itself, separately storable, queryable, and renderable on demand.
> For document-oriented applications, W3C Annotations are likely the right
> carrier for provenance attestations, playing the same role that VC comment
> blocks play in source code.
>
> Your just-in-time compositor idea is interesting. An LLM directed to
> assemble a WebFinger server, a contract, or a diagnostic report from
> verified components is already performing composition. Making that process
> explicit as a reproducible build step, with the materialised artifact
> carrying provenance annotations throughout, is a natural evolution. Whether
> you keep the materialised artifact for auditing or discard it after
> compilation or execution is a deployment choice, not an architectural one.
>
> bob wyman
>
>
>
> On Thu, Apr 2, 2026 at 10:03 AM Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
> I wrote a similar tool in the early 80s called:
>
> PINC: A Tool for Maintaining Configurable Software in Pascal
>
> https://share.google/aimode/mt3UfoPjvqyIg5gY3
>
>
>
> In addition to Verifiable-Certified (V-C) functions, you can also support
> multiple alternative V-C implementations of a V-C interface or functional
> specification. For example, different sorting algorithms that share a V-C
> Sort() interface.
>
>
>
> A V-C embedded in a VC is easily supported using a GitHub repository, for
> example. A VC document registry can be virtually any content store. It's
> easier to maintain a single file per function than two.
>
>
>
> Build yourself a just-in-time V-C source code compositer.  When fully
> materialized, you can through the composited code project away once it is
> compiled or keep it around for debugging.
>
>
>
> Michael Herman
>
> Web 7.0
>
>