Re: [PROPOSED WORK ITEM] Cryptographic Event Log

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
>