Re: [PROPOSED WORK ITEM] Cryptographic Event Log

 Interesting work, glad to see it. We’re exploring similar concepts working
on World.

Importantly, we can’t treat all data as embedded in the log itself. We have
a need to store files and/or archives of files that are addressable
independently from the archive.

This is also useful for pruning old state if necessary.

Curious what you think,
Gabe

On Jul 14, 2025 at 6:52:53 AM, Leonard Rosenthol <lrosenth@adobe.com> wrote:

> In Content Credential parlance, we use a feature we call ingredients (
> https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#ingredient_assertion).
> A simple chain is done via `parentOf` ingredients.   You create a new
> manifest (either regular or update) representing the new actions (etc.)
> taken, and include an ingredient assertion to the previous instance.   In
> media, this would be where (for example) you open an image in an editor,
> make some changes, and then save – the original is the `parentOf` the new
> one.  Same with your log model.
>
>
>
> One difference is that we don’t restrict each entry/Manifest to a single
> event (or what we call an action) – you can have multiple actions, and
> potentially others statements (what we call assertions) in each one.
>
>
>
> Leonard
>
>
>
> *From: *Dmitri Zagidulin <dzagidulin@gmail.com>
> *Date: *Sunday, July 13, 2025 at 9:42 PM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>
> *Cc: *Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <
> public-credentials@w3.org>
> *Subject: *Re: [PROPOSED WORK ITEM] Cryptographic Event Log
>
> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>
>
>
> Hi Leonard,
>
>
>
> I'm wholly with you -- evaluating existing solutions for fit is incredibly
> important when developing new specs! Huge fan of that approach. And hey,
> who doesn't like hearing that somebody has already done the hard work (of
> spec writing and library implementation) for them, and so we can move on to
> other projects! :)
>
>
>
> Since you mentioned that the Content Credentials C2PA spec would fit the
> use case (a general purpose cryptographic event log), I read through it
> (and the related Attestations spec), to see if we can use any pieces from
> it.
>
>
>
> So, what we're talking about when we say cryptographic event log is a
> linked list of objects, with each entry having hash-bound pointers to the
> previous entry in the list.
>
>
>
> The closest thing I could find to this, a general purpose hash chain,
> would probably be the Update Manifests section of the Content Credentials
> spec?
> https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_update_manifests
>
>
>
> Is that accurate, or where would you recommend we look instead?
>
>
>
> If that's the section you meant, I'm not sure it would fit our purpose for
> the event log. Partly because - I couldn't figure out how backwards hash
> links are expressed, for the update manifest. And also, the entries to the
> manifest seem fairly constrained to C2PA stuff, including strict
> restrictions to the c2pa.actions property, etc?
>
>
>
> For comparison, this is what a hash chain / cryptographically bound event
> log looks like in the did:webvh spec:
> https://identity.foundation/didwebvh/next/#the-did-log-file
>
> A pretty basic list of objects, with flexible properties in 'parameters',
> and the 'entryHash' of the previous object being placed in the 'versionId'
> object.
>
>
>
> Would we be able to model something like that with C2PA manifests data
> models or something similar?
>
>
>
> Thanks,
>
> Dmitri
>
>
>
>
>
> On Sun, Jul 13, 2025 at 2:19 PM Leonard Rosenthol <lrosenth@adobe..com>
> wrote:
>
> >Today, there is no standardized data structure for a cryptographic event
> log.
>
> >
>
> While we refer to it as a content provenance system, I would strongly
> argue that the Content Credentials technology from C2PA (https://c2pa.org)
> serves the purpose you describe :
>
> *express changes to data over time and the means for a verifier
> tocryptographically verify those changes.’*
>
>
>
> Perhaps, before creating a new specification, evaluation of this (and
> possibly other solutions in use today) would be the right approach.
>
>
>
> Leonard
>
>
>
>
>