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

Hi Markus, Manu, and all,

Following Markus's question about alignment between verifiable history
formats (webvh, webs/KERI, CEL) - I'd like to suggest that Glogos might
serve as a complementary substrate layer for did:cel, rather than another
competing format.

Glogos is a minimal attestation protocol:

{
  "zone": hash(public_key),           // Who
  "subject": hash(content),             // What
  "canon": hash(interpretation),     // How
  "time": unix_timestamp,              // When
  "refs": [attestation_ids],               // Causal chain
  "proof": ed25519_signature        // Binding
}

Universal Anchor: GLR = SHA-256(""). A mathematical constant anyone can
derive.

How this substrate could complement did:cel:

1. Witness Layer: Glogos attestations can serve as witness proofs for CEL
entries. The refs DAG provides causal ordering without relying on external
timestamp services.

2. CEL Mapping: Each CEL entry maps naturally to the substrate:
   - zone = DID controller
   - subject = hash(DID Document)
   - refs = [previous_cel_entry, witness_attestations]

3. Universal Root: GLR provides a mathematical root that all CELs could
trace to, addressing the "where does the chain start?" problem.

4. Witness Economics: Instead of asking "who runs witnesses?", the DAG
provides self-witnessing. Anyone who creates an attestation referencing
yours becomes an implicit witness.

Bonus / Alignment: Glogos uses self-certifying identifiers (ZoneID =
hash(Pubkey)), making it naturally compatible with the did:scid model. It
also interoperates with did:key via alsoKnownAs, providing an
infrastructure-free upgrade path.

Resources:
- Spec: https://github.com/glogos-org/glogos
- Genesis: 2025-12-21T15:03:00 UTC (Winter Solstice)

Happy to discuss how this substrate approach might inform the alignment
conversation.

Best regards,
Manh Thanh Le

On Sat, Jan 3, 2026 at 1:44 PM Markus Sabadello <markus@danubetech.com>
wrote:

> Yes, did:scid should be mentioned in this context..
>
> We have done a demonstration where did:scid can use different verifiable
> history formats (webvh, webs) and different ways of finding the log (via
> HTTPS, or DID URL, or Hedera URL, etc.).
>
> There is a DID parameter called "src", which seems to be pretty much the
> equivalent of "storage" in the did:cel specification.
>
> Here are some examples and a working demo:
>
> https://github.com/danubetech/uni-resolver-driver-did-scid?tab=readme-ov-file#example-dids-and-did-urls
>
> And a video with some explanation:
> https://www.youtube.com/watch?v=bO5CbSPAS-k
>
> Not sure what to do about the apparent situation that there exist now
> these various different formats for verifiable history logs (webvh,
> webs/KERI, CEL), needs more discussion I guess to see if alignment is
> possible at this stage...
>
> Markus
> On 12/23/25 2:01 AM, Stephen Curran wrote:
>
> It's a reasonable idea.  Since the log defines the verifiable history,
> independent of discovery, the log can be stored in different places and
> processed consistently.
>
> The folks at Affinidi/First Person Project that have implemented the
> did:scid:vh spec have been able to show exactly that is possible --
> although it becomes a bit "meta-meta". "did:scid" itself is a called a meta
> model.
>
> Boiled down, that implementation uses the did:webvh log format for DIDs
> published in different places -- web servers, databases, blockchains, etc..
> The DID itself has no discover data in it (just the prefix and the SCID),
> and the location is determined in other ways that enable retrieval of the
> Log (e.g. query parameter, known registries, etc.).  Once the Log is
> retrieved, the same did:webvh rules for the processing of the verifiable
> history are executed to verify/resolve the DID Doc.
>
> On Sat, Dec 20, 2025 at 6:52 PM Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
>> 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> 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> wrote:
>>>
>>>> On Sat, Dec 13, 2025 at 11:23 PM Otto Mora <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>
>>>>> 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.
>>
>>
>
> --
>
> Stephen Curran
> Principal, Cloud Compass Computing, Inc.
>
>