Re: did:cel - a cryptographic event log-based DID Method

On Fri, Dec 12, 2025 at 11:53 AM Patrick St-Louis
<patrick.st-louis@opsecid.ca> wrote:
> Having worked extensively on implementing webvh in a production environment, I would like to clarify some points. I agree with most of what was said, however some points are not representative of features provided by webvh.

Great, thank you for chiming in with corrections, Patrick! I've been
meaning to learn more about did:webvh and this is a good exercise to
do so.

Can you be more specific about "production environment" -- any
deployment numbers you can share? Just trying to get an idea of the
scale at which did:webvh is operating. Any lessons learned that would
be helpful to the broader community?

> I'm not sure backwards compatibility is the appropriate term, but you can certainly publish a parallel did:web by following the specification.

The way I first learned about did:webvh was as a "fully backwards
compatible set of extensions to did:web". Which means, if someone used
a "did:web:domain.example" identifier, they wouldn't have to change it
at all, but would benefit from did:webvh's additional features. I
probably misunderstood what the actual proposal was, which was the
"parallel" path you mentioned, and not the more unified path I had
imagined.

This has consequence to some of the production systems we're involved
with, which used "did:web" and I was imagining that we could tell
those customers: "You can keep using your same did:web identifier, but
now there are optional and additional layers of security you can
depend on for higher-security use cases." -- but what it sounds like
you're saying is that it was never on the table as an option... you
have to switch over to the new identifier format, which means they
might as well be switching to an entirely different DID Method and now
we can't tell their IT teams that they're fully in control of their
identifier as a result of their control over the domain, which is
something these IT teams are very comfortable with.

I don't think they will be very comfortable with the notion that the
domain-based identifier isn't tied to the domain which they control.
One of the strongest arguments for did:web was the "You control the
domain, and therefore you control the DID, always." line. Some of the
customers we have are going to be very hesitant to move away from that
model, and I was hoping we'd be able to ratchet up the security with
did:webvh up without giving up that notion of "domain lock" (in a good
way).

> This can address scenarios such as:
> - An organization using did:web who wants to upgrade to webvh, benefiting from the features of being able to detach from their domain in the long run without losing their permanent identifier.

Yes, but that's an anti-feature to some of these organizations...
namely people in their IT security teams. They are comfortable with
domain-based identifiers and removing that from the security model is
viewed as a negative thing, at least for the time being. It might take
years for these more conservative organizations to become comfortable
with their "identity" being detached from their domain.

> > did:cel has a heartbeat mechanism to prevent historical forking and/or log truncation/rollbacks, did:webvh does not.
>
> WebVH doesn't implement a heartbeat functionality, it instead has 2 features which each on their own can prevent forking, witnessing threshold and pre-rotation. This being said, a heartbeat functionality would be trivial to add, and would be super effective in conjunction with pre-rotation. Currently, a controller can implement its own "heartbeat mechanism" by publishing a new log entry on a regular basis.

I don't think that's right -- unless you have a rule that says: "The
DID Document is deactivated unless updates are made every N time
units", you have the risk of rolling back history to the time of a
compromised key (in the past, when the document existed on an old,
compromised domain), even with witnessing thresholds and pre-rotation.

You can execute this attack just by compromising the web server. With
did:webvh, watchers are the only thing that could detect this sort of
rollback, but then that's extra infrastructure that you need with
did:webvh that you don't need with did:cel... and even if you have
watchers, you are not guaranteed that someone is watching the
particular DID you're interested in... which might be the common case
(for individuals), because the vast majority of verifiers in the world
probably don't care about your personal DIDs, until you use them, and
when you use them, no one had been watching your DID history.

Yes, did:webvh could add this functionality, just like did:cel could
add all of did:webvh's functionality, but there seem to be differing
philosophies at play here. I don't think did:cel has a need for
witnesses that see every transaction, nor watchers, as a core part of
the system.

> > did:webvh has pre-rotation commitments, which might address attack windows after the latest heartbeat present in did:cel (unless the pre-rotation key is compromised).
>
> I disagree that a compromised pre-rotation key in itself is a sufficient attack vector.

Ah, I wasn't saying that... I was trying to say: This is a place where
did:webvh has a clear advantage over did:cel, so perhaps we should
look into pre-rotation commitments as a part of did:cel. That is, get
rid of using the authorizationMethod to sign the transaction, and just
include a pre-rotation secret. I hesitate to say that the pre-rotation
secret should be a key as then you have to manage the rotation of
hundreds to thousands of keys, and with commercial hardware HSMs, that
can get expensive. So expensive, that I expect implementers will move
the secret management out of the HSM and make their system more
vulnerable to attack. That said, need to think about this more as that
might not be the case.

> Furthermore, keys are segmented for their use cases, as opposed to did:cel, where the same key is used to sign the logs and as a verification method. It gives more power to a compromised key.

Yes, I agree that's a weaker position than I'd like for did:cel and
agree that did:webvh's segmented key use is probably a better approach
(as you know, these things are not difficult to change). I'm
questioning whether the pre-rotation secret needs to be a key,
though... or just a secret of some kind. I'm also wondering if it
matters -- the real power is in the pre-commitment to the recovery
key, which can (in theory) undo the sorts of attacks we are talking
about... so why bother with a per-event pre-rotation key... it's more
to manage, more complexity, possibly resulting in a weaker security
profile around the key (due to commercial cost), when you could just
commit to an offline recovery key and leave it at that.

>> What I would prefer is for did:webvh to commit to a single root of trust, the domain, if you lose your root of trust, you have lost control of your DID.
>
> AFAIK this is what webvh wanted to address from the start, preventing committing to the domain as the root of trust. The point of webvh is to initiate your log (create the did), then have the log history carry the identifier (SCID) across domains in a detached operation if need be, while preserving authenticity.

Yes, well this was clearly a misunderstanding on my part. I thought
some of the goals of did:webvh was around upgrading the trust that the
domain really does contain the appropriate did:web document, and to
enable history on that did:web. What I'm learning now changes my
understanding of did:webvh significantly... it's more like did:cel
than I had thought, but loses some key features of did:web that feel
like they're going to create a customer problem for us.

> Something else to add, with webvh, the witness proofs are kept separate from the log file. This was designed to improve performance on larger logs, since the witness file can be truncated without affecting the authenticity of the log history.
>
> With did:cel, depending on the size of the history, there will be a performance impact. It would be great to compare performance results of did cel with what was calculated through webvh benchmarks.
> The use of jsonl for the webvh log also enables streaming the log which is another performance improvement over larger json files.

We've done little benchmarking, but what we have done has convinced us
of a few things:

1. There is no need for a binary format for the log.

2. The JSON-lines based approach doesn't provide a significant
performance boost (and requires state to provide a performance boost,
which did:cel tries to NOT require).

3. We've simulated 30+ years of key rotations (every 3 months) and
heartbeats on a DID Document (without key removals), which results in
a gzip'd log file of around 46KB for an individual, and around 604KB
for a government agency. The government agency one is probably a bit
off because it has over 240 keys in the DID Document over that period,
when in reality, keys would be removed over time. We need to implement
key removal after rotation for did:cel before we get to some more
realistic numbers... but neither of those file sizes or download sizes
seem very scary... and that's without any sort of optimization.

> As for the series of questions about webvh and scids and how verifiers should build their software around it, these could be better answered during a working group call. I would be happy to share our approach, as I'm sure other implementers will be.

Yes, I agree that diving deep into all of this would be a good next
step... especially once the DID Methods WG has been spun up.

> Thank you for providing this detailed overview as a start to the conversation, hopefully some of these misconceptions can be ironed out.

Yes, and thank you for engaging in the conversation as well and
clearing up some of those misconceptions. I really appreciate it,
Patrick. :)

-- manu

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

Received on Saturday, 13 December 2025 21:24:25 UTC