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

Hi Melvin

Thank you for coming up with this first draft I think it’s a good start and
we can host it under version control as you deem appropriate and then
include that to the main work item, I am in full support of it as this is
going to be very helpful

Hi Manh

I would answer the DAG part based on my technical insight , DAG here would
be useful if we can implement a mechanism like IOTA does for M2M
transactions, necessitating the users of the network to first verify two
prior logs and then only their log can be verified considering the security
scenario

Regards


On Sun, 4 Jan 2026 at 7:59 PM, Manh Thanh Le <vnlemanhthanh@gmail.com>
wrote:

> Hi Melvin,
>
> Thank you for the comparison framework — this is exactly
> what the discussion needs.
>
> On Question #1 (DAG vs Heartbeat):
> Yes. A refs-based DAG provides cryptographic temporal proof
> without requiring periodic entries. Each reference is itself
> a witness.
>
> On universal anchoring (potential addition to comparison):
> Any hash-based method could anchor to SHA-256("") — a
> mathematical constant derivable by anyone. No central log
> required: the DAG structure itself is the log.
>
> Possible table row:
> | Method     | Can Anchor to GLR? | Notes
>     |
> | did:key      | N/A                            | Ephemeral
>               |
> | did:cel       | Yes                            | Could reduce heartbeat
> need |
> | did:webvh | Yes                            | Via refs extension
>          |
>
>
> Best regards,
> Manh Thanh Le
> ---
> Related exploration:
> github.com/glogos-org/glogos/blob/main/GENESIS.md#appendix-z-cross-network-interoperability
>
> On Sun, Jan 4, 2026 at 3:51 PM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> ne 4. 1. 2026 v 7:58 odesílatel Amir Hameed <amsaalegal@gmail.com>
>> napsal:
>>
>>> Hey All, it’s very hard to follow the whole thread and especially the
>>> priors methods which I am sure must be taken into account before we go into
>>> full discussion, I would suggest if we can create a tabular data document
>>> where all existing methods their strengths, weakness and infrastructure can
>>> be compared so that once we move ahead with CEL we have the whole context
>>> of how DID evolved since its inception. That would help us have better
>>> clarity.
>>>
>>> Regards
>>> Amir Hameed
>>>
>>
>> Hi Amir, all,
>>
>> I agree with Amir’s suggestion that a comparative document would be very
>> helpful. Having followed DID method evolution since the early
>> blockchain-based approaches, I think a structured comparison could give the
>> group shared context and reduce repeated re-litigation as we discuss
>> did:cel.
>>
>> Below is a *draft comparison framework*, intended as a starting point.
>> Corrections and additions are very welcome.
>> ------------------------------
>> DID Methods – Draft Comparison Infrastructure & Cost
>> Method Infrastructure Required Estimated Cost DNS Dependency
>> did:key None Zero No
>> did:web Domain + HTTPS server ~$10–50/year Yes
>> did:webvh Domain + HTTPS + version log ~$10–50/year Yes
>> did:cel File storage + 3+ witnesses Near-zero No
>> did:nostr Public Nostr relays Near-zero Optional
>> did:ion Bitcoin node + IPFS (or provider) Variable (BTC fees) No
>> did:indy Permissioned ledger membership Network-dependent No
>> Security Properties
>> Method Key Rotation History Verifiable Censorship Resistance Fork
>> Protection
>> did:key No (new DID required) N/A N/A N/A
>> did:web Manual replacement No Low None
>> did:webvh Yes (logged) Yes Medium Pre-rotation
>> did:cel Yes Yes High Heartbeats
>> did:nostr Via events Via relays High Relay consensus
>> did:ion Yes (Sidetree) Yes (blockchain) High Bitcoin finality
>> did:indy Yes Yes (ledger) Medium Ledger consensus
>> Privacy Considerations
>> Method Resolution Tracking Witness Visibility Correlation Risk
>> did:key None N/A High
>> did:web Server logs N/A High
>> did:webvh Server logs Witnesses see content Medium–High
>> did:cel Storage logs Oblivious (hash only) Medium
>> did:nostr Relay logs Relays see events Medium
>> did:ion IPFS / node logs N/A Medium
>> did:indy Ledger queries logged N/A Low (ZKP)
>> Operational Characteristics
>> Method Offline Create Offline Resolve Implementation Complexity Spec
>> Maturity
>> did:key Yes Yes Very low Stable
>> did:web No No Low Stable
>> did:webvh No No Medium Draft
>> did:cel Yes No (cacheable) Medium Draft
>> did:nostr Yes (basic) Yes (basic) Low–Medium Draft
>> did:ion No No High Stable
>> did:indy No No High Stable
>> ------------------------------
>> Key Trade-offs (Brief)
>>
>>    -
>>
>>    *DNS vs non-DNS:* did:web and did:webvh leverage DNS trust but
>>    inherit its failure modes; did:cel and did:nostr avoid DNS entirely but
>>    raise discovery and UX questions.
>>    -
>>
>>    *Optionality:* did:webvh supports many optional features, increasing
>>    flexibility but also the security analysis surface; did:cel aims to reduce
>>    optionality to simplify guarantees.
>>    -
>>
>>    *Witness models:* visible witnesses vs oblivious witnesses vs
>>    blockchains present different privacy and trust trade-offs.
>>    -
>>
>>    *History guarantees:* both did:webvh and did:cel provide verifiable
>>    history, but via different mechanisms and threat assumptions.
>>
>> ------------------------------
>> Questions for the Group
>>
>>    1.
>>
>>    Would a DAG structure materially improve fork detection over linear
>>    history plus heartbeats?
>>    2.
>>
>>    What long-term incentive models make sense for witnesses?
>>    3.
>>
>>    How should migration from did:web to did:webvh or did:cel be handled?
>>    4.
>>
>>    Should the CCG define a shared DID-method comparison and test suite?
>>    5.
>>
>>    Given overlapping goals, should did:nostr be compared more formally
>>    alongside did:cel?
>>
>> ------------------------------
>> Suggested Next Steps
>>
>>    -
>>
>>    Create a living comparison document (HackMD or GitHub).
>>    -
>>
>>    Invite method authors to review and correct entries.
>>    -
>>
>>    Add implementation status, deployments, and failure-mode analysis.
>>
>> I’m happy to help maintain or contribute to such a document if there’s
>> interest.
>>
>> Best regards,
>> *Melvin*
>>
>>
>>>
>>>
>>> On Sun, 4 Jan 2026 at 12:05 AM, Manu Sporny <msporny@digitalbazaar.com>
>>> wrote:
>>>
>>>> Hey folks,
>>>>
>>>> Given the discussion over the past several weeks around did:cel,
>>>> here's the work item adoption tracker issue:
>>>>
>>>> https://github.com/w3c-ccg/community/issues/255
>>>>
>>>> Please provide additional support in that issue if you haven't already
>>>> done so via the mailing list.
>>>>
>>>> Thanks to everyone that has commented with suggestions on how we can
>>>> potentially further align work happening in this area. I'll try to
>>>> follow up on some of the comments that came in over the holidays to
>>>> provide some more thoughts on alignment.
>>>>
>>>> -- manu
>>>>
>>>> --
>>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>>> Founder/CEO - Digital Bazaar, Inc.
>>>> https://www.digitalbazaar.com/
>>>>
>>>>