Re: [PROPOSED WORK ITEM] CEL DID Method (did:cel)

On Sat, Jan 17, 2026 at 9:05 PM steve capell <steve.capell@gmail.com> wrote:
> I’m interested because I have an inkling that did methods based on witnessed event logs can solve some long standing business challenges in a very robust, scalable, interoperable, and cost effective way.

Yes, to your notion that witnessed event logs can solve some long
standing business challenges in supply chain. I would make your
statement broader than DID Methods, though, which is what the CEL spec
is about -- DID Documents are just one thing that has state that can
be summarized in a CEL, but I wouldn't focus on DIDs as the enabling
technology -- the enabling technology is a cryptographic event log
with witnesses, heartbeats, and decentralized storage. More below...

> Does too much optionality in did:webvh present a security risk? There’s truth in that but my instinct says that it’s not black and white but rather a question of degree.

Yes, agreed, and I believe there's rough consensus that it is a
question of degree.

At some point on one end of the spectrum, you don't have enough
features for people to care, and then somewhere at the other end of
the spectrum, you have too many features that can be implemented
and/or combined in unexpected ways that scares people away.

For example, IMHO, TTL at the log-level is of questionable value (but
it probably doesn't lead to a security concern)... however, domain
portability does have value (and it definitely leads to a security
concern for some use cases -- like where you definitely do not want
domain portability to even be an option because your production
operations people are probably going to forget to turn the feature
on/off based on the use case). IOW, you don't even want the feature to
be there, and if it's mandatory to implement, you don't want to NOT
implement it and then have a non-conforming implementation.

So, yes, it's not black or white, which is why optional features get
debated... and the more optional features there are, the more debate
there will be.

> Someone in the meeting said “why not have a suite of quite specific profiles?” Which resonated with me.

Yes, and some might say: That's called a DID Method. :)

... and the counter-argument is: But DID Methods can have optionality
within them, which is also true. So, now we're just talking about what
options are acceptable to the broadest base of implementers/deployers
per DID Method.

There are, of course, details here that matter so if we are going to
converge on a minimum set of DID Methods as a community (which is the
goal), then we need to talk about those details.

> What matters is that the market sees consensus and value in the options and clear guidance on when to use which feature for what business purpose.

Yes, absolutely, this is another thing where I think there is rough
consensus that this is the best outcome. I know others might be
dismayed by the discussion, and it really would be good if we could
agree on one DID Method for all of our use cases, and if we can't do
that, then the smallest possible number to address the broadest
possible set of use cases.

Since the early days of DIDs, the community has been pretty consistent
that we believed only a "handful" of DID Methods would end up
surviving long-term -- implementers only have so much time and
attention to analyze a DID Method and tend to just use what others in
their ecosystem are using. "More than two, but less than 10" was the
general feeling at the time, and probably is to this day.

Yes, having 250+ DID Methods doesn't help implementers pick one, which
is what the upcoming W3C DID Methods WG and DID Method standardization
at DIF are attempting to address... and this conversation about
did:webvh and did:cel is a part of that "building consensus" process.
I'm going to respond to that particular item in a separate thread, as
this email is already pretty long and I wanted to engage with some of
your points without diving into any of them at depth (in this thread,
at least).

> How to resolve a did:cel document given the did:cel identifier?

You get a DID URL with a `storage` parameter that tells you where to go:

did:cel:IDENTIFIER?storage=STORAGE_URL

There is an example of how that happens in a protocol here:

https://w3c-ccg.github.io/did-cel-spec/#did-authentication

> there seemed to be some thinking that perhaps it’s not important to be able to find that storage location from the did itself because that can be handled through some controller-verifier out of bounds path.

That might be a misperception -- it is important, but the hint is in
the DID URL, not the DID itself.

The design decision made in did:cel was: Placing a variable storage
location in the DID itself is probably the wrong thing to do because
you want the DID to stay static for very long periods of time where
the storage location could change many times throughout that period.
It's an architectural layering decision where there is a clean
separation between the long lived identifier and the short lived
storage location.

> That presupposes that the controller and verifier are in some kind of direct communication (eg a holder presenting to a verifier).

No, it doesn't -- you can provide the DID URL in any field that takes
a URL... including the credentialSubject.id, proof.verificationMethod,
and so on. No direct communication necessary (and this is more or less
what did:webvh has to do, too).

> How to choose witnesses (controller) and how to trust witnesses (verifier)?  It seems to me that trustworthy witnesses are pretty fundamental to both methods.

Both methods have traditionally taken different approaches to
witnesses. did:cel requires oblivious witnesses while did:webvh had
the witnesses actually looking at the contents of the log. did:webvh
might change that requirement based on our latest discussion.

Remember that "trust" is wholly based on your perspective. If you are
a verifier in Country A, which does not have a good relationship with
Country B, you probably won't pick Country B as your sole witness.

did:cel is designed for adversarial witness networks. The more
adversaries you can get to witness your event log, the higher the
global trust will be in your event log. That is, if you can get both
Country A and Country B to witness your event log, it's better than
just getting Country A or Country B alone to witness your event log.

Ultimately, the controller wants to pick a set of witnesses that is
going to give them the highest level of acceptance among the broadest
set of witnesses, even when verifiers explicitly distrust a certain
subset of witnesses.

> what stops me creating an entire 2-year event log in two seconds by choosing three buddies to act as witnesses and lie about timestamps?

Do most/all of the verifiers you will be interacting with trust those
witnesses? If so, yes, that is a possible attack vector. :) If you, as
a verifier, want to prevent that attack vector, you're going to have
to insist on a larger collection of witnesses that you are pretty sure
aren't going to collude in that way, a blockchain-based DID Method, or
a different DID Method entirely.

Now, there are market forces that can correct lying witnesses -- if it
ever got out that a witness was lying, they'd be put on just about
every deny list that you could imagine. There are audits that could be
done to assert that specific versions of "known good software" were
being run for particular witness services, etc.

> Some kind of directory of reliable witnesses seems like a handy thing.... So the answer to the question of which witnesses do we both trust could be “anyone on the GRID”.

Yeah, that would be one strategy among many that would help the
ecosystem, and anchoring it at the UN would be a great addition to the
ecosystem. Amir's point about over-centralization standing, I expect a
number of trusted institutions to publish their list of trusted
witnesses.

We would be grateful to you for seeing what you might be able to do
given your position as UN/CEFACT Vice-Chair.

> Other stuff.  There’s more questions like when is a did:cel a heartbeat valuable (even indispensable) and when does it not really matter?

Heartbeats matter when you want to prevent hostile storage services
from rolling your DID history back or attackers from abitrarily
forking your DID after they have stolen one of your keys.

You can prevent that from happening if you have some other thing in
the ecosystem that is protecting you from that (like did:webvh
Watchers). However, since Watchers aren't mandatory, I believe that
did:webvh DID controller's could see rollback/fork attacks if the
system managing the DID has a compromise of a historical key. I have
not thought deeply about what it means to not have heartbeats and not
have a watcher so I might have that totally wrong.

Hope that helps reflect on some of your thoughts, Steve... interested
to hear what you think about all of that.

-- manu

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

Received on Monday, 19 January 2026 21:25:59 UTC