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

On Mon, Dec 15, 2025 at 12:30 PM Patrick St-Louis
<patrick.st-louis@opsecid.ca> wrote:
> Myself and I'm sure other webvh folks would be more than happy to clarify some points during a call.

Yes, let's do that -- it needs to happen as I'm concerned that some of
the responses seem to indicate that people think that did:webvh and
did:cel are meant to be competitive, and while they have some common
features, I had originally intended them to be complimentary... where
did:webvh focused on domain-bound things and did:cel focused on
cryptographic ID-bound things. I can see now (because I missed some
features in did:webvh) that some see them as competitive, which wasn't
the intent, but I can understand the interpretation. In any case, more
collaboration will hopefully lead to mutual progress.

> I'd be happy to provide numbers for production deployments but what I think is most relevant
> is the governance models that were able to be met through technical webvh features.
> The lessons learned and decision making through implementations are more valuable IMO.

Well, yes, lessons learned are valuable; agree with that. What I was
trying to get at is: How baked is did:webvh? Because if millions of
people are using it, we don't have as much latitude to change it, but
if we can change it, then perhaps we have more latitude to get at the
core of the set of use cases each is designed for while minimizing the
attack surface for both methods... or, come to a common set of
features and one DID Method (though, I am skeptical that we can do
both domain bound and self-certifying bound in the same DID method
with an acceptable attack surface). I know that's what did:webvh is
proposing, but as I said, I'm not sure the combinatorial nature of the
did:webvh parameters leads to a clean security story (without smarter
infrastructure that's harder to implement correctly for verifiers).

> I'm not sure where the notion that webvh isn't compatible with did:web is coming from.

I thought that did:webvh was an extension to did:web (with verifiable
history). What I am coming to understand is that the domain-bound part
of did:webvh can be turned on and off (effectively forking the
security model), depending on what the controller wants, and that
complicates the security profile for verifiers. It's the domain
portability aspect of did:webvh that is not compatible with did:web
(which does not have domain portability). Now, some see that as a
feature, which is fair -- I can see the benefit. Presently, though I
mostly see it as a bug that increases the attack surface, but perhaps
it's only because I haven't had time to become comfortable with the
idea. DID Methods that are able to change the way their root of trust
is calculated are concerning to me, but perhaps I'm the only one.

> We would need more information about the "more unified path" you envisioned,
> and where this is diverging with the current spec.

I hope the above makes it more clear. I thought did:webvh was ONLY
about adding a witnessed history to a did:web document, but it seems
to be something that is that AND a number of other features that
change the way you calculate the root of trust (again, because I
misunderstood).

> For the portability concerns, Brian has answered this.
> Portability can be disabled at creation.

Yes, and anytime thereafter, possibly in unrecoverable ways by an attacker.

> This leaves the watchers, which I see as similar to cel storage services.
> While it's true that a watcher is an additional infrastructure requirement,
> so are CEL storage services.

No, the two aren't the same. Watchers are far more complex than CEL
storage services. Watchers have a relationship with the DID controller
that is more complex than a DID controller has with a CEL Storage
Service. For example, Watchers publish an HTTP API that is specific to
did:webvh:

https://identity.foundation/didwebvh/v1.0/#watcher-http-api-operations

CEL Storage Services just require an HTTP GET to retrieve the log and
that's it. How you get the log onto the server is out of scope (for
now), but could be as simple as a HTTP PUT w/ an authentication
signature. While this part of did:cel is underspecified, I don't think
it's accurate to say Watchers and CEL Storage Services are equivalent.
As far as I can tell, they are quite different with far more
complexity baked into Watchers than CEL Storage Services.

> I think a pre-rotation commitment would be an interesting feature for did:cel.

Yes, agreed, and if we were to do that, we would get rid of the DID
Method counter-signatures on the operations. The downside there is
that it would bloat the log, possibly by a very large margin.

> Something else I would like for did:cel is to lean in IPv6 usage for storage services.
> IPv6 has fantastic promise and this is a great use case.

Yes, we need to make sure we can go full IPv6 (or atleast IPv4) and
ensure HTTPS connections. The thing we have to make sure is that there
are enough TLS certificate issuers that support IPv4 and IPv6
certificates and look into IP lease lengths for both IPv4 and IPv6
(for example: can you guarantee leases for decades at a time). I know
I've had my static IP taken away from me, by my ISP being acquired
(for example). If we can get some strong guarantees there, I expect we
might drop DNS entirely from did:cel for storage services and
witnesses. This, again, gets at the optionality for a DID Method and
did:cel attempting to aggressively reduce optionality as much as
possible.

> Most examples of storage services given are reliant on DNS (such as the gh pages).
> I'm not opposed to DNS, but if non reliance on DNS is one of the core benefits of did:cel,
> examples should follow suit.

Yes, agreed.

> Does did:cel do anything different that the current cel spec? Meaning is there additional
> stuff that needs to compliment the cel spec to enable this or was the current cel spec sufficient?

IIRC, the current CEL spec was mostly sufficient. Most of what did:cel
adds is the state machine verification bits for a DID Document
(signing operations and heartbeats), which is expected of any protocol
that builds on top of the CEL spec.

We might want to move the concept of signing operations and heartbeats
into the CEL spec, but I'm a bit concerned about doing that because
not every use case needs a heartbeat and oblivious witnessing might be
good enough for some use cases. I don't think we'll know for sure
until we get the 2nd and 3rd application-layer specs for did:cel.
Social Web use cases might be the second application-layer spec, and
if so, those might need a different construction for object updates
than what did:cel does because there would be way more data involved
(messages, audio, images, video, etc.). There are, however, other "who
currently controls this resource" use cases (such as land deeds,
vehicle ownership, etc.) that aren't as complex as Social Web use
cases, and that have government involvement as a backstop for corner
cases (theft, forking, etc.),  that might be easier to pursue than the
Social Web use cases.

> Discovery is another topic that is currently elusive IMO.

Discovery for did:cel is performed by the client sending the discovery
endpoint to the verifier. As I mentioned in a previous post, I'm
concerned about the attack surface here. We could upgrade to a DHT or
similar mechanism, but that adds infrastructure complexity that feels
like a bridge too far for something that is supposed to be able to be
bootstrapped by a small community with little compute and financial
resources.

> Overall I think the cel spec is valuable and having this as a first tangible use case is great.

Sounds good, Patrick... thanks for the input above, and I hope my
responses help clarify some of the previous miscommunications
throughout the thread. Let's have that call in the new year, even if
the DID Methods WG is delayed waiting for a Chair from a W3C Member to
step forward to lead the group.

-- manu

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

Received on Saturday, 20 December 2025 16:58:32 UTC