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

Stephen, I'm wondering if this conversation is beginning to suggest that did:webvh become a DID metamethod? Some of Manu's comments steered me this direction. did:webvh becomes the metaspec for an entire family of methof features.

Then stakeholders can carve out the specific did:webvh DID method *profile* that meets their specific requirements e.g. the did:webvh CEL DID method profile.

Food for thought,
Michael Herman
Decentralized Systems Architect
Web 7.0 / TDW AgenticOS™



Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: Stephen Curran <swcurran@cloudcompass.ca>
Sent: Wednesday, December 17, 2025 5:50:48 PM
To: Patrick St-Louis <patrick.st-louis@opsecid.ca>
Cc: Filip K <filip26@gmail.com>; Otto Mora <omora@privado.id>; Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG <public-credentials@w3.org>
Subject: Re: did:cel - a cryptographic event log-based DID Method

Hi all,

I wanted to add my perspective as an editor of the did:webvh spec on the recent did:cel announcement and this discussion. Given how close the two methods are in design and intent, I’m concerned about the risk of unnecessary fragmentation, and I’d like to share a few technical observations—especially where did:webvh can readily incorporate ideas introduced by did:cel and its perceived shortcomings.

I've taken a look at the did:cel spec and this email chain and have these thoughts on the differences, focusing on the new features and the "did:webvh" shortcomings from Manu's emails on this chain.

On the "new" features of did:cel and their relevance to did:webvh

  *   The "heartbeat" idea is useful and an easy addition to did:webvh because of the existing "parameters" concept, allowing the DID Controller to commit to a maximum time between Log Entries and defining what a resolver should do it that commitment is not followed. It does require a spec change for the next version but very easy to both spec and implement. I don't think that there are "differing philosophies in play". We just didn't think of that feature, we like it, we'll likely add it.
  *   Making the DNS part of a did:webvh DID optional is a topic we have discussed several times in the did:webvh Working Group and are already considering for the next version.  As the verifiability of a did:webvh starts with the SCID, the DNS portion is not so much a "hard requirement" (as Manu puts it) as for ease of discovery.  We also think that a DID without discovery information is "not as clean as we would like" (again, as Manu puts it), but there are certainly use cases where it would work -- peer DIDs, ecosystems where a DID repository is in a known place (did:plc), and the query parameter approach as used by did:scid and did:cel.
  *   Oblivious witnessing: Super interesting to think about.  did:webvh has deliberately made the technical approaches simple/clear and left governance up to the ecosystems using did:webvh.  Technically, did:webvh supports exactly "oblivious witnessing" as described by the did:cel spec -- the witness generates a proof of the hash of the log entry. That said, we did put in the spec that the witness "must verify the log entry being witnessed", but we can (and will likely) remove that line, as that is a governance -- and we should not dictate that. With that, we have oblivious witnesses.

So these are all easy changes to the did:webvh spec. Requires a new version, but easily fitting in the design and we definitely appreciate the ideas!

On some of the comments from Manu earlier in the chain about did:webvh shortcomings:

  *   "did:webvh identifiers are not stable".  If a did:webvh DID is portable and "moved", it is by definition a new DID, but retains its SCID and verifiable history. This opens new use cases (porting the DIDs reputation when moving DID publishing platforms) and eases the transition when its storage location must change. Portability is thus an optional feature, not a bug.  Counter -- what happens when a did:cel uses the ?storage... form when issuing millions of credentials, and the storage location goes away?
  *   "did:webvh has pre-rotation commitments". That is a feature that did:cel should consider. Easy to specify, optional, and adds security -- if it is wanted/needed.
  *   "did:webvh requires heavier, stateful infrastructure (witnesses, domains, and watchers)".  Leaving domains aside for now, did:webvh does not require that infrastructure -- it is up to the ecosystem using did:webvh. For ecosystems that require external verification, and longevity (decades), did:webvh provides technically simple approaches that enable ecosystems to decide on how to use (or not) those features.
     *   If an ecosystem (such as the Pharma industry) requires that watchers be in place for decades in case the DID Controller goes out of business, did:webvh gives them a method to do so.
     *   If an enterprise wants to apply governance/policy rules about DIDs published by their sub-entities, they can require they witness DID Log Entries before publication (as BC Gov is doing now with did:webvh).
     *   Regarding domains -- did:cel acknowledges that "storage" is necessary--some place to store the DID Doc. That's infrastructure and did:webvh's can be just as light or heavy.
  *   "the use of JSON Lines requires state". This is a benefit -- a DID resolver can choose to trade off state for speed with JSON Lines. With did:cel's structure, there is not such an option -- you have to retrieve/process the entire log.
     *   That said, we're likewise pretty happy with the performance of did:webvh -- here's a benchmark for a 10 year-old DID, updated monthly, with multiple witnesses: https://didwebvh.info/latest/faq/Performance/

  *   "did:webvh...fully backwards compatible set of extensions to did:web" -- I'm not sure where that came from. Here is what we did do:
     *   Put no constraints on the DID Doc contents -- the DID Controller can put anything they want in the DIDDoc.  Same as did:web.
     *   Make it so that there is a mechanical transformation to go from the location of a did:web DID Doc to a did:webvh DID Log (literally -- "add an 'l' to the end of the HTTP URL path"). That allows a publisher of a DID to publish both, and a resolver to check to see if a did:web has an equivalent did:webvh that it could use to further verify the DID.
     *   A DID Controller can easily transition to from did:web to did:webvh by publishing a did:webvh and applying the mechanical steps to publish the corresponding did:web in parallel.

I hope we can get together and discuss these in the future -- hopefully in a W3C DID Methods Standardization Working Group.

On Mon, Dec 15, 2025 at 9:32 AM Patrick St-Louis <patrick.st-louis@opsecid.ca<mailto:patrick.st-louis@opsecid.ca>> wrote:
I didn't want to side track the conversation towards webvh, only pointing out some inaccuracies in the comparisons.

Myself and I'm sure other webvh folks would be more than happy to clarify some points during a call.
This being said I'll try to keep this response brief so we can focus the conversation around did:cel.

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.

I'm not sure where the notion that webvh isn't compatible with did:web is coming from.
Webvh is a mechanism which can be used to add a verifiable history to a web did (pre-existing or new)
by publishing a log file in a location adjacent to the did document, hence the term parallel.
Updates to this document will then need to be captured through a new log entry,
and no longer exist in a vacuum.

If this feature isn't clear from the specification (which I believe it to be),
it will need to be addressed because this is core to webvh.
We would need more information about the "more unified path" you envisioned,
and where this is diverging with the current spec.

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

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.

I think a pre-rotation commitment would be an interesting feature for did:cel.
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.
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.

An additional question:
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?

Discovery is another topic that is currently elusive IMO.

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

Regards,
Patrick

On Mon, Dec 15, 2025 at 10:21 AM Filip K <filip26@gmail.com<mailto:filip26@gmail.com>> wrote:
On Sat, Dec 13, 2025 at 11:23 PM Otto Mora <omora@privado.id<mailto:omora@privado.id>> wrote:
...
Could you suggest what would be the economical or other type of incentives that would motivate an organization make a witness server available?

Hi,
that is the question I am trying to answer as well: who would be motivated to run witness services, ideally at little or no direct cost?

The combination of the heartbeat mechanism and witness services is the core innovation. For this model to work, there must be a sufficient number of independent witness services available to support a reasonable threshold, e.g. 3-to-10, and diversity.

Totally blind witness services should be inexpensive to operate and carry minimal risk. Identity managers and wallet operators are likely to be the most motivated participants. e.g. “Use our identity manager to gain access to a large and diverse set of witness services (and, on top of that, use our "AI" to select the right set for you ;).”

Verifiers and infrastructure providers may be less directly motivated, but their participation adds diversity to the ecosystem and makes it function effectively.

Just loud thoughts,
Filip
https://www.linkedin.com/in/filipkolarik/


I have often wondered how proponents of did:keri and similar methods like to claim that they do not need to use a blockchain VDR, but instead they swap out the blockchain VDR with a network of witnesses that need to exist and it's not always clear what would motivate entities or organizations to make such infrastructure available. In public blockchains it is a bit more clear to me, because there is an associated transaction fee that you pay for submitting transactions to the VDR such that they are recorded.

Thank you,

Otto Mora


On Mon, Dec 8, 2025 at 9:57 AM Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> 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/


--
Manu Sporny - https://www.linkedin.com/in/manusporny/

Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/




--

Stephen Curran
Principal, Cloud Compass Computing, Inc.