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

On Thu, Dec 11, 2025 at 9:54 AM Dmitri Zagidulin <dzagidulin@gmail.com> wrote:
> Could you say a few words about how this method is positioned relative to did:webvh?

I haven't spent too much time thinking about how did:webvh and did:cel
are positioned relative to one another other than the loose notion
that I think they are complementary. So please take the rest of this
as just "thinking out loud".

Organizations will probably prefer did:webvh for a long time to come
because it's built on things (domains and websites) that their IT
teams are comfortable with managing. This is why did:web is popular
today, and I expect many to move over to did:webvh for the added
security benefits it provides. In fact, what I hope we do is just
incorporate most of did:webvh into did:web so everyone just has a
smooth upgrade path to all the good features in did:webvh.

Individuals might prefer did:cel because it provides an option to them
for a fully decentralized DID Method where they don't have to worry
about domain rental cost and/or the DNS system depriving them of their
identifier via coercion or censorship. While did:cel can use the DNS
system, it is not dependent on it and I'm wondering how far we should
push that part of did:cel. For example, should we only allow witnesses
and storage services that use IPv4/IPv6 addresses? Ban usage of domain
names? It feels like a bridge too far to force on everyone using
did:cel, but it is still a valid option for those that want
independence from a possible point of coercion/censorship.

There are features that did:webvh and did:cel share, such as
self-certifying identifiers and witnesses, and it's possible for both
to have watchers. There are also migration features that did:webvh
achieves in different ways than did:cel. So, there are similarities
there where we might claim that they're both feature equivalent for
those features. That said, I do think there are details about how each
are implemented that do provide important nuance that has tangible
security outcomes over time.

For example, I do have security "gut reaction" concerns about the SCID
and domain transfer features in did:webvh. I say "gut reaction"
because I haven't studied the attacks on those features in did:webvh
very closely, so it could be that my concerns are easily addressed via
some text in the spec that I haven't read yet. Also, my concerns
aren't to knock did:webvh's overall utility; I expect our organization
will implement did:webvh in our open source tools and products once
it's through the standardization process at W3C (which I expect will
result in some changes).

All that said, here are some concerns I have about did:webvh that I
don't think exist with did:cel.

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). The did:webvh folks will have to weigh in on whether this
backwards compatibility still exists... the latest spec seems to
require SCIDs now where it didn't before?

If SCIDs are now mandatory, but domains are still a part of the
identifier, I am concerned about what systems are supposed to do with
that sort of setup. Is the SCID the identifier that goes in the
database, or do you store the domain as part of the identifier? Is
equivalence done on just the SCID itself, or do you include the
domain? If there is a key/domain compromise, does the attacker get to
rewind history on the old domain? What is a verifier supposed to store
locally and how do they detect a legitimate domain transfer? What are
the ramifications of not having a heartbeat... does pre-rotation
provide an equivalent mitigation against key compromise?

Put another way, a DID Method has to root its trust in something, and
did:webvh seems to say something to the effect of "The domain name is
part of the trust model, like did:web, except when it isn't"... and
maybe the domain isn't a part of the trust model for did:webvh, and if
that's the case, why is the domain in the permanent identifier for
did:webvh? 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. Allowing DIDs to move domains, where the
domain is a part of the DID, feels like it creates an attack surface
that could be exploited by bad/naive implementations, and it certainly
confuses what part of the identifier is permanent vs. what part of it
is temporary.

I do also have concerns that witnessing in did:webvh isn't oblivious.
If you don't do oblivious witnessing, you enable the witnesses to make
decisions on whether or not to witness based on the contents of a DID
Document. That can lead to all sorts of bad things, like Denial of
Service based on who you are and/or the sort of update that you are
doing.

All of that will need more discussion, and perhaps after that
discussion we'll find out that did:cel really doesn't add anything
above and beyond did:webvh, and all we really need is did:webvh, which
would be a fine outcome.

Presently, I think these features between did:cel and did:webvh are
effectively the same:

1. The DID contains a cryptographic hash of the initial state of the
DID Document.

2. There is a hashlinked log of changes to the DID Document.

3. Each log entry is witnessed by one or more external parties.

4. The cryptographic log can be retrieved over HTTPS.

5. You can recover the DID Document if keys are compromised in some cases.

6. Data Integrity and ecdsa-jcs-2019 is used to secure each log entry
and Multihash is used to link log entries together.

These things feel different enough to matter:

1. did:webvh has a hard dependency on DNS, did:cel does not.

2. did:cel has a heartbeat mechanism to prevent historical forking
and/or log truncation/rollbacks, did:webvh does not.

3. did:webvh identifiers are not stable throughout time, did:cel
identifiers are stable (domain portion is a part of the DID URL, not
the DID itself).

4. Witnesses in did:webvh aren't oblivious, which means there are
legal implications to them witnessing vs. in did:cel where witnessing
is oblivious/blind which prevents certain kinds of coercion,
censorship, and Denial of Service in general.

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

6. did:webvh requires heavier, stateful infrastructure (witnesses,
domains, and watchers) where did:cel does not require stateful
infrastructure, does not require the use of domains.

Those are just off the top of my head, and again, we need to work with
the did:webvh folks to tease through the items above, and the
inevitable items I missed or forgot to include in the list above.

One of the main motivations behind did:cel was to be able to say: We
have an option for a fully decentralized DID Method for the upcoming
W3C DID Methods WG that does not depend on DNS (to address the
"centralization concerns"), does not use a DLT (to address the
blockchain concerns), and uses Web technology (HTTPS, to justify the
work being done at W3C). With did:cel, I think we can realistically
meet each class of DID Method the DID Methods WG claimed they would
create. I don't mean that it's the only way we can achieve that goal,
but I would feel much better about our prospects with did:cel (and
did:webvh) in the running.

Did that answer at least some portion of the question you asked, Dmitri?

-- manu

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

Received on Thursday, 11 December 2025 22:33:26 UTC