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

Hi Manu,

The did:webvh method is flexible in regards to portability in order to
appease to IT departments that want to ensure domain binding. There is a
*portable* flag that can be set to true to allow a DID to move to another
domain but it has very strict requirements. Here they are pulled from the
spec


   - Can *ONLY* be set to true in the first entry.
   - Defaults to false if omitted in the first entry.
   - Retains value if omitted in later entries.
   - Once set to false, *MUST NOT* be changed to true.


Does that help with your uneasiness?

After reading the did:cel spec I’m not totally clear what the heartbeat
feature gives you. I get that it helps determine liveness but I don’t know
if that is a problem I’ve heard people complain about. To me it feels like
it’s bloating a log that already has the potential to get quite large.

Can you explain the benefits of keeping an up to date heartbeat?

Generally I’m glad to see this come around. I believe a standardized and
generalizable cryptographic event log is powerful for many use cases and
DIDs are just the tip of the iceberg.

Thanks,
Brian

On Sat, Dec 13, 2025 at 1:26 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

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