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

On Fri, Dec 12, 2025 at 2:54 AM Markus Sabadello <markus@danubetech.com> wrote:
> Nice. It seems to be very similar to the did:scid approach:
> https://lf-toip.atlassian.net/wiki/spaces/HOME/pages/88572360/DID+SCID+Method+Specification

Yep, there are certainly similarities:

1. Hash-based identifier based on initial record and initial record
commitments, and
2. Ability to move storage location of DID Document over time.

I think all the methods supported by did:scid have that capability,
whether they're DLT-based or not.

While did:scid could support did:cel, as you mentioned, the other is
not true due to the minimalist design approach taken with did:cel. For
example, I don't expect did:cel would support multiple DID Methods
like did:scid does due to the increased operational complexity that
approach creates (slightly different trust models between DID Methods
means a verifier has to know about and mitigate each trust model
separately, effectively having to fully implement and secure four
different DID Methods instead of one).

did:scid feels like it has to be an all or nothing thing -- either the
verifier has to accept all DID Methods supported by did:scid, or if it
doesn't, there will be interop issues by partial implementations
(which would be bad because you can't just say "support did:scid", you
have to specify the subprofiles as well).

The benefit of did:scid is the large net it casts, but I wonder how
difficult it might be to prove the security model against a particular
use case (since did:peer and did:webvh do have very different threat
models). I, for one, would have a hard time convincing our customers
to support it based on that alone. Again, I expect this sort of
discussion to come out in the DID Methods WG analysis.

And again, to be fair, I haven't taken any time to do the security
analysis on did:scid... and that will be extra work that would need to
be done for did:scid in the WG.

> Maybe the name of the DID parameter could be aligned between the
> methods, i.e. decide whether to call it "src" or "storage"...

Yes, certainly we should do /at least/ that. As I mentioned in my
previous off-the-cuff comparison w/ did:webvh, there are some core
features that are shared between several DID Methods.

It feels like did:webvh, did:cel, and did:scid could at least settle
on making the storage location a query parameter (did:webvh doesn't do
this today, I don't think?), and the name of the query parameter that
lists the storage location. The next, more difficult, thing might be
to agree on the identifier format (Multibase + Multihash header)...
with log format being more challenging to agree on, as well as details
around the witness and watcher functionality.

Again, all stuff for discussion in the DID Methods WG once it gets started.

-- manu

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

Received on Saturday, 13 December 2025 20:08:57 UTC