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

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.

> did:webvh seems to have shifted from being backwards-compatible with
did:web (a good thing), to being incompatible with did:web (not so great).

I'm not sure backwards compatibility is the appropriate term, but you can
certainly publish a parallel did:web by following the specification. This
has been demonstrated in several pilots.
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.
- An organisation is required to have a did:web as part of some of their
interactions.

The alsoKnownAs has been a core feature for some time.

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

> 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. There would also need to be unauthorized access to a witness
service (or many, depending on the threshold value set) along with
witnessing rules bypass, and unauthorized access to the storage location of
the log. Additionally, pre-rotation keys are discarded every log, so the
alleged attack window would be brief. 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.

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


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.


Overall, I think the comparison is a good start. I'm sure other things will
come to mind and others will chime in.

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.

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

+1 to Markus comments about aligning the query parameter

On Fri, Dec 12, 2025 at 2:53 AM Markus Sabadello <markus@danubetech.com>
wrote:

> Nice. It seems to be very similar to the did:scid approach:
>
> https://lf-toip.atlassian.net/wiki/spaces/HOME/pages/88572360/DID+SCID+Method+Specification
>
> E.g. a did:cel like this:
>
>
> did:cel:zW1poyeoHaT1WftFBG8WKa6fCaH98tbKKMrkJWDqFeohTz1?storage=https%3A%2F%2Fstorage.example%2Fdids%2F
>
> Could also be expressed as a did:scid like this:
>
>
> did:scid:cel:zW1poyeoHaT1WftFBG8WKa6fCaH98tbKKMrkJWDqFeohTz1?src=https%3A%2F%2Fstorage.example%2Fdids%2F
>
> Maybe the name of the DID parameter could be aligned between the
> methods, i.e. decide whether to call it "src" or "storage"...
>
> Markus
>
> On 12/8/25 3:54 PM, Manu Sporny wrote:
> > Hi all,
> >
> > The DID Methods WG Charter is going up for a W3C Member vote soon and
> > one of the DID Method types it contemplates standardizing is a fully
> > decentralized DID Method. The Cryptographic Event Log[1] was adopted
> > as a Credentials CG work item earlier this year, is listed in the new
> > DID Methods WG charter, and hinted at a DID Method that was powered by
> > the technology.
> >
> > This email is to introduce did:cel, a fully decentralized,
> > cryptographic event log-based DID Method:
> >
> > https://digitalbazaar.github.io/did-cel-spec/
> >
> > The goals of this DID Method are:
> >
> > Minimal Infrastructure - A single individual with a file hosting
> > location can create and control multiple DIDs in a way that the
> > identifiers are highly-available and globally recognized.
> >
> > Near-zero Cost - The cost to create and control multiple DIDs is not
> > burdensome to at least 70% of the world's population, which are the
> > number of people that have access to the Internet as of 2025.
> >
> > Censorship and Coercion Resistant - The oblivious witness and file
> > storage services used to manage a DID cannot censor or coerce an
> > individual or organization to any significant degree.
> >
> > No Centralization - Witness and file storage services are abundant,
> > easy to operate at scale, and are easily interchangeable if they
> > become non-responsive or compromised.
> >
> > Over the years, there are many of us that have invested in DLT-based
> > DID Methods and have not seen their usage grow at the rate we would
> > wish. There are a number of reasons for this, but many of them boil
> > down to implementation and operational complexity as well as
> > significant infrastructure and transaction costs. The did:cel DID
> > method focuses on reducing each of those costs as much as possible.
> >
> > Please take a look at the spec and let us know what you think. Raise
> > issues here if you find anything of concern:
> >
> > https://github.com/digitalbazaar/did-cel-spec/issues
> >
> > We are currently looking for support and co-editors for this work item
> > in the W3C CCG and will raise an issue to call for adoption once we
> > have a week or two of discussion on this mailing list. If you are
> > supportive of this work, please let us know via the mailing list.
> > Happy to answer questions and concerns in the meantime. :)
> >
> > -- manu
> >
> > [1] https://w3c-ccg.github.io/cel-spec/
> >
>
>