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

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