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

On Thu, Dec 11, 2025 at 8:30 AM Will Abramson <will@legreq.com> wrote:
> Interesting work, I like the heartbeat and blind witnessing features. Also, very comprehensive privacy and security considerations!

Thanks, Will, much appreciated! :)

> One question I had was around how the Read operation works. How does a resolver determine which storage locations to query for the CEL?

The short answer is that, on first use, the hint is provided via a
query parameter in the DID URL. Every resolution after that can just
use the CelStorageService information in the latest DID Document.

An example of how this plays out in a DID Authentication is provided here:

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

or how it plays out in a Verifiable Presentation is shown here:

https://digitalbazaar.github.io/did-cel-spec/#verifiable-credentials

It's not as clean as I'd like it to be, but since we can't count on
DNS, or a DLT, I think this is the trade-off; more verbose DID URLs on
first use.

It's still not clear if we should specify a better discovery mechanism
than that in the current spec. Discovery is largely considered out of
scope in the current spec, with only one direct way of providing a
storage location (the `storage` query parameter). In the future, there
might be a DHT that provides the same sort of discovery mechanism. One
of the goals of the method was to try to minimize the amount of
infrastructure necessary to create and verify these sorts of DIDs, and
while we could have specified a DHT for the lookup mechanism, we
didn't because 1) that might not be the best way to do in the long
run, and 2) we didn't want to introduce extra infrastructure and
governance if we could avoid it.

I'll also note that the Read section isn't written yet because I'm
waiting to see what folks think about this approach before settling on
it. There are some attacks, such as the attacker providing a
non-standard storage location and the verifier needing to detect that
by cross-referencing the provided storage location, with the latest
storage location in the CEL, and then possibly shifting to the newest
storage location if things change over time... or what to do if your
storage locations disagree on the current state of the CEL (right now,
longest CEL history wins).

But the short answer to your question is that you, the verifier,
receive a message that contains a DID URL that looks something like
this:

did:cel:zW1poyeoHaT1WftFBG8WKa6fCaH98tbKKMrkJWDqFeohTz1?storage=https%3A%2F%2Fstorage.example%2Fdids%2F

... which tells you that you can download the CEL by dereferencing this URL:

https://storage.example/dids/did:cel:zW1poyeoHaT1WftFBG8WKa6fCaH98tbKKMrkJWDqFeohTz1.cel.gz

... and then you ensure that the CEL you receive contains that storage
service in the latest DID Document version contained in the log.

Did that answer your question, Will?

-- manu

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

Received on Thursday, 11 December 2025 19:26:25 UTC