- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Mon, 14 Jul 2025 13:52:53 +0000
- To: "dzagidulin@gmail.com" <dzagidulin@gmail.com>
- CC: Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <DS0PR02MB9150AA846B1673DEC2106F78CD54A@DS0PR02MB9150.namprd02.prod.outlook.com>
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<mailto: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<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 Monday, 14 July 2025 13:52:59 UTC