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

ne 4. 1. 2026 v 15:39 odesílatel Amir Hameed <amsaalegal@gmail.com> napsal:

> 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
>

Thanks Amir, the DAG discussion is fascinating. I've used linear logs
(simpler to implement), but DAG seems better suited for multi-stakeholder
scenarios where parallel updates are needed. Systems like RGB use DAG
structures, and have gained popularity. Does that match your thinking?


>
> 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/
>>>>>
>>>>>