Re: [PROPOSED WORK ITEM] Cryptographic Event Log

This is also the same problem domain as KERI's Key Event Log, which has a
formal spec and implementations in python, javascript, and rust.

On Sun, Jul 13, 2025 at 2:44 PM Dmitri Zagidulin <dzagidulin@gmail.com>
wrote:

> 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
>>
>
>
>

Received on Sunday, 13 July 2025 22:36:54 UTC