Re: Granularity of events (was Re: [PROPOSED WORK ITEM] Cryptographic Event Log)

On Sun, Jul 20, 2025 at 3:27 AM Leonard Rosenthol <lrosenth@adobe.com> wrote:
> I am happy to write up a more detailed evaluation comparing C2PA’s Content Credentials with CEL.

Great, thank you Leonard -- that'll help us all figure out where
things are aligned and where things need more work.

> Currently CEL only does one “event” per “entry”.  There is no model for grouped or related “events”.  I am not clear on all the use cases for CEL, but in ones that I am envisioning – especially in areas such as Agentic protocols – it is certainly a requirement to have multiple “events” as part of a single signed “entry” from a given “entity”.
> @Manu Sporny Is this something that the CEL team has discussed or considered?  If so, can you give insight into the chosen direction?

CEL was really designed to focus on tracking ONE top-level
entity/object throughout its lifespan. CEL is on the more
decentralized part of the spectrum when it comes to "tracking changes
on objects", and by that I mean there are separate logs per object
instead of the typical blockchain approach which is to put all of the
objects in a single log.

With the CEL spec, we presume higher level protocols will add in
"multiple events" through the top-level data object being tracked if
they need to track multiple events/objects, but by default, we pick
the simplest, most decentralized way of state tracking.

In other words, CEL made a specific design decision to focus on
something that was simple to implement and that wouldn't create
complex state-machine logic (changes to a single data structure --
like a DID Document or ActivityPub Post, -- throughout time). This
approach was taken because when you have multiple events, there is a
chance that each event might create a conflict with another event in
the event group. For example, if you have an update and a deactivate
event in the same event array, and the update comes in after the
deactivate, but each event is signed by a different but authorized key
-- which one takes precedence? The spec would have to consider forking
and then define forking logic and, as a result, become more complex.

Now, there is a downside to this decision -- you just push the
complexity up the stack to the application layer. The problem doesn't
go away, it is just handled at a higher layer in application-space...
but even then, it's a bit simpler for application space to deal with a
data structure where there is a very clear order of operations on a
single object. If the deactivate/update scenario happens above, when
you have single events, then the logic is clear -- the update fails
because the object has been deactivated. So, an order is forced,
whereas if a different approach is taken, extra logic needs to come
into play for the state machine code.

That said, people are free to build their own data structures that
track multiple objects and make simultaneous changes to those
objects... and the spec should probably warn against doing that since
it creates complexity for state machine algorithms.

I think I remember reading that the C2PA stuff does allow multiple
events, which would be one of the deltas. Is that so, and if it is,
perhaps you found a good way to mitigate the forking issue I'm
highlighting above? It's not that it's not possible to create forking
logic in the spec, but it adds complexity and the value proposition to
forking isn't very clear.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Sunday, 20 July 2025 13:53:44 UTC