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

On Sat, Dec 13, 2025 at 9:08 PM Brian Richter <brian@aviary.tech> wrote:
> 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... Does that help with your uneasiness?

Yes, it certainly helps address the concern I've seen large
organizations have wrt. not having their domain be the root of
authority for resources associated with them.

It does, however, raise another concern around optionality in
did:webvh where now the domain is the part that matters and the SCID
has far less of a role (if any) to play in the security of a DID
Document. For those organizations, which I would assert are the vast
majority of organizations, all the extra functionality is attack
surface that they don't want... so why not just stick to did:web (plus
a log of some kind) instead? For the organization that only wants
domain binding, the SCID and all the other functionality doesn't
really provide any additional value, does it? I get that it provides
ecosystem value, but that value is of no consequence to the
organization that wants to establish control through the DNS.

I also wonder if there is an attack here, where an attacker either
breaks into a website or takes over a domain, and deactivates domain
transfer? Since the operation is permanent and undoable, this would be
fairly catastrophic for someone that wanted to migrate domains
eventually. Remember that breaking into a site often gives you access
to the subsystems of that site, including HSMs and signing (unless the
security team has done their best to separate the system that
generates the DID Document and log, and shut off access from the
outside world, from the system it is hosted on). I need to think about
this attack more, though, as there are other did:webvh parameters that
might prevent it... and compromising a pre-rotation key might just be
an accepted risk (if it happens, you're hosed).

The counter-argument to all of this is, of course: Only use the
features you want, you don't need to use all the parameters that
did:webvh provides. It's the optionality being dormant and then being
activated by an attacker that tends to concern me (about any DID
Method, not just did:webvh). did:cel attempts to focus on removing as
much optionality as possible while keeping the use cases broad enough.
For example, did:cel isn't for organizations that just want domain
binding -- if you want that, use variations of did:web*

> 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.
> Can you explain the benefits of keeping an up to date heartbeat?

The heartbeat feature is there not to determine liveness, but to
protect the log from arbitrary rewrites based on a key compromise to a
past key. It prevents forking from any point in history and narrows
the forking possibility to just the latest heartbeat timeframe, which
you can recover from via a recovery key (if needed).

Now, perhaps did:webvh achieves that through throwing away its
pre-rotation key on every log change... but if that key is compromised
(e.g. bad implementation forgets to delete the keys and keeps them
live and accessible), seems like a fork can happen from any point in
history. The heartbeat is a sort of decentralized multi-factor
protection against arbitrary forking in did:cel.

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

Good to hear, and yes, the goal is to go beyond DID Documents w/
cryptographic event logs... this use case is an attempt to see if the
core data structures are useful for DID Documents, and then move onto
other arbitrary data object types.

-- manu

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

Received on Friday, 19 December 2025 22:50:09 UTC