Re: [PROPOSED WORK ITEM] Cryptographic Event Log

I would personally be very interested in exploring how something like CEL
could be used to build a novel VC credentialStatus type/method.

An example I can provide would be a Verifiable Credential which represents
an asset, and the event logs could record ownership transfers and
information.

Instead of having a "belongsTo" property within the credential subject,
this "OwnershipStatus" could be tracked outside of said Verifiable
Credential, with a link included in a credentialStatus property.

This is just one concrete example of how I could see something like CEL
enabling an assortment of interesting status mechanisms that doesn't rely
solely on statusLists.

On Sat, Jul 19, 2025 at 6:36 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Sun, Jul 13, 2025 at 10:27 PM Michael Prorock <mprorock@mesur.io>
> wrote:
> > Hate to ask you to spend more explanation time Manu, and appreciate the
> write up so far, but would you mind breaking out key differences you see
> from keytrans (and also SCITT from a more general digital notary
> perspective)?
>
> Noting the feedback from Leonard, Daniel, Melvin, Christopher, Gabe,
> and Dmitri regarding "Can you compare CEL to X", it's going to take
> some significant effort to compare/contrast each of these
> "cryptographic log" formats against each other. :)
>
> I'll note that doing these comparisons was the very first issue raised
> on the spec:
>
> https://github.com/digitalbazaar/cel-spec/issues/1
>
> ... and I've added the more recent mentions here:
>
> https://github.com/digitalbazaar/cel-spec/issues/1#issuecomment-3092587006
>
> All that to say that the work needs to be done for each technology
> mentioned in issue #1. That will take time and that's what incubation
> is partly about. Thankfully, Wolf has already done the comparison to
> Provenance Marks.
>
> So, in an attempt to provide at least a preliminary answer to each of
> you in a single email:
>
> Christopher and Wolf, Provenance Marks seem very close to what CEL is
> trying to do. I'm most curious about the pre-commitment approach that
> PMs use. It feels like we might be able to combine CEL/PMs or at least
> re-use some of the functionality from PMs in CEL. Ideally, for me,
> we'd join forces and merge the two but I'm saying that without
> understanding every technical decision made in the PM spec.
>
> Leonard, you described a way we could use a subset of C2PA to achieve
> the same goals as CEL. I think the next step there is to try to
> achieve each use case and example put forward in the CEL spec and see
> what the C2PA solution looks like -- do some analysis on the two.
>
> MikeP, there are a number of conceptual similarities between
> SCITT/COSE Receipts, etc. The biggest set of differences seem to be
> that SCITT seems to focus on CBOR/COSE, use binary merkle trees and
> inclusion proofs, and then builds from there, which the other
> approaches don't seem to take for whatever reason. Similar to C2PA,
> we'd just have to mark up the examples in CEL and see what the log
> looks like and how easy folks feel it would be to implement. SCITT
> doesn't seem like an easy implementation lift whereas the did:webvh
> folks have noted that their log mechanism, which is very similar to
> CEL, only takes a week or two to implement fully. Again, it's going to
> take time to do that analysis.
>
> Daniel, similar response as to Leonard and MikeP -- we'll need to see
> how the use cases covered via CEL compares to KERI when KERI is used
> as the underlying technology.
>
> Melvin, if you look section "2.5 Minimizing Event Logs", we might do
> that compression using CBOR-LD, for which there has to be a JSON-LD
> context. That said, we're trying really hard to not require JSON-LD at
> all. You're right, we want to avoid friction; if the past several
> years have been a lesson to us, introducing JSON-LD adds A LOT of
> community friction. It's not clear it's mandatory for this particular
> use case (though you can get benefit if JSON-LD is additive, but not
> mandatory).
>
> Dmitri and Brian, yes, of course we're going to learn from
> did:webvh... and it might be that CEL moves closer to did:webvh
> (possibly even just re-using the log format entirely). In this way,
> perhaps the final solution will be a merge of did:webvh's log format,
> PMs, and the CEL spec. Time will tell.
>
> I'm sure those responses are not satisfying; they don't come close to
> answering "How is CEL different from X". We acknowledge that those
> questions need to be answered in time if CEL (or whatever variation of
> it) is to be promoted beyond incubation. This email response is just
> noting that we are tracking the "analysis of prior art" request as an
> issue and still need to do the work to explore the alternatives at
> depth.
>
> If anyone has additional technologies to add to the list of "How is
> CEL different from X", please add them here:
>
> https://github.com/digitalbazaar/cel-spec/issues/1
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>