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

Dear Steve,


Thank you for these insights. Your perspective on market confusion and the
risks posed by fragmented DID methods is a vital reality check for the
community. The danger of the market retreating to a “known,” yet flawed,
method such as did:web purely for the sake of clarity is something we
should actively work to prevent.


Based on our experience at Sirraya Labs, I would like to offer three points
to build on your foundation:

------------------------------

1. Proof of Scale: The DID–VC–JWT Bridge


We have been operating a full production ecosystem for over a year using a
DID–VC–JWT bridge, demonstrating that interoperability does not require
waiting for a distant or theoretical future.


   -

   The result: Our system bridges traditional web standards (JWT) with
   decentralized identifiers (DIDs) across multiple method implementations.
   -

   The lesson: It works, it scales, and it is demonstrably superior to
   centralized systems because it preserves local control while remaining
   “liberal in what it accepts” in the spirit of Postel’s Law.


This approach shows that backward compatibility with today’s web and
forward compatibility with decentralized identity are not mutually
exclusive.

------------------------------

2. The Trap of Government Control


While the GRID project provides a valuable directory of trust anchors, we
should be cautious about positioning governments as the primary “witnesses”
or controllers of DID infrastructure.


   -

   The risk: If governments control resolution or witnessing, the core
   property of censorship resistance is fundamentally weakened.
   -

   The principle: DID and VC standards should serve as an open blueprint,
   not as a mandate for a specific government-operated infrastructure.


If we allow the ecosystem to revert to a centralized gatekeeper model, then
traditional databases—cheaper and faster—would suffice, but they would lack
the sovereign protection that decentralized identifiers were explicitly
designed to provide.

------------------------------

3. Elevating did:cel to a “Meta-Method” Blueprint


Rather than selecting a single “winner” among did:cel, did:webvh, or other
approaches, I suggest rethinking the role of did:cel itself.


   -

   The proposal: Elevate did:cel from a specific DID method into a modular
   meta-method blueprint.
   -

   Concept: It would define a uniform causal structure (i.e., how identity
   events are created, updated, witnessed, and resolved), while allowing key
   components to be swapped as modules:

   -

      Resolution: DHT, IPFS, web-based, etc.
      -

      Witnessing: peer-based, GRID-based, ledger-based, etc.
      -

      Discovery: in-band or out-of-band mechanisms.



By making these components modular and method-agnostic, we enable
developers to preserve existing investments while converging on a shared
structural foundation.


This approach provides the market consensus you described, without
suppressing innovation or forcing premature architectural uniformity. It
ensures a consistent core essence across implementations, while still
supporting the business-case-specific profiles that real deployments
require.

------------------------------

I would welcome the opportunity to explore how this meta-method concept
could be formalized and advanced within the UN/CEFACT community.


Kind regards,

Amir Hameed Mir

Founder, Sirraya Labs

https://www.sirraya.org


On Sun, 18 Jan 2026 at 7:38 AM, steve capell <steve.capell@gmail.com> wrote:

> Hello colleagues,
>
> I’ve had a look at the draft did:cel and at did:webvh and, yes, even at
> the keri stack which also has the idea of the event log and witnesses.  I
> also listened-in on the recent call about the potential for alignment
> between did:cel and did:webvh.  I’m not a hard-core expert in this stuff
> but I’m interested because I have an inkling that did methods based on
> witnessed event logs can solve some long standing business challenges in a
> very robust, scalable, interoperable, and cost effective way. It is in this
> context that I offer some thoughts here.
>
>
>    - *Does too much optionality in did:webvh present a security risk?*
>    There’s truth in that but my instinct says that it’s not black and white
>    but rather a question of degree. Optional features generally map to
>    business use cases and may exist for a very valid business reason. Some is
>    good (if there is a genuine business reason for them) and too much is bad.
>    Someone in the meeting said “why not have a suite of quite specific
>    profiles?” Which resonated with me.  So long as the combination of options
>    remains practical and viable for implementers to accomodate then Postel's
>    law applies - “be conservative in what you do (aka issue) and be liberal in
>    what you accept (aka verify) from others”.
>    - *Why does harmonising matter?* There is a valid argument that says
>    “don't pick a winner, let innovation flourish and let the market choose”.
>    Yes, but if the market perceives chaos then it will choose none. I think
>    the 100’s of me-too cryptocurrency Ponzi did methods in the early days did
>    us no favours. The market saw too much confusion and self-interest so
>    either left it alone or picked the one method that seemed reasonable which
>    was did:web (despite it’s know limitations and vulnerabilities).  Now we
>    are publishing did:webvh and did:cel and some others and risking the same
>    market perception.  But it doesn’t have to be that way. Last time it was a
>    market free-for-all. This time it’s a decent group of people discussing how
>    to compose/combine valuable business features.  So whether we end up with
>    one did method with well defined profiles or a small bunch of different
>    narrowly scoped did methods doesn’t matter.  What matters is that the
>    market sees consensus and value in the options and clear guidance on when
>    to use which feature for what business purpose.
>    - *How to resolve a did:cel document given the did:cel identifier? *I
>    understand that the traditional did document is actually composed by the
>    verifier by traversing the event log. And that the event log can be stored
>    anywhere. However there seemed to be some thinking that perhaps it’s not
>    important to be able to find that storage location from the did itself
>    because that can be handled through some controller-verifier out of bounds
>    path. That presupposes that the controller and verifier are in some kind of
>    direct communication (eg a holder presenting to a verifier). In all my use
>    cases (supply chain) this assumption is completely invalid. A did:cel
>    controller in an exporting country may use it to issue all kinds of
>    credentials like invoices, certificates, and so on. Those credentials may
>    pass through many hands before they arrive at a verifier like the importing
>    customs authority - who will have no way at all to ask the controller for a
>    pointer to the event log location. So, for me did resolvability is a
>    mandatory feature. Not that every use case needs it but because some cant
>    live without it.
>    - *How to choose witnesses (controller) and how to trust witnesses
>    (verifier)? * It seems to me that trustworthy witnesses are pretty
>    fundamental to both methods. I understand that they are just blind notaries
>    that timestamp and sign a hash - but what stops me creating an entire
>    2-year event log in two seconds by choosing three buddies to act as
>    witnesses and lie about timestamps?  Some kind of directory of reliable
>    witnesses seems like a handy thing. Coincidentally we might be able to
>    offer one here at the UN because of the GRID project
>    <https://un.opensource.unicc.org/unece/uncefact/gtr/>.  The Global
>    Registrar Information Directory (GRID) is a list of authoritative register
>    DIDs (and other meta-data) including things like national business
>    registers, trademark registers, land registers, etc.  The idea is that
>    anyone that controls a self-issued did (eg a did:cel) can choose (if they
>    wish) to prove that they control their did to an authoritative register who
>    will then issue a VC attesting to the link between the did and the register
>    entry. This facilitates trust in trade because the did:cel (or other did
>    method) holder can prove that they are not only the controller of the did
>    but also the authorised officer of business XYZ or legitimate owner of
>    trademark ABC.  Anyhow, it occurs to me that we could propose that these
>    authoritative registers also offer anonymous witness services. So the
>    answer to the question of which witnesses do we both trust could be “anyone
>    on the GRID”.
>    - *Other stuff*.  There’s more questions like when is a did:cel a
>    heartbeat valuable (even indispensable) and when does it not really
>    matter?  All these questions boil down to your use case.
>
>
> So here’s some use cases
>
>    - Transferrable records.  A vast amount of international trade (which,
>    please remember is 25% of the world economy so not a niche use case)
>    depends on things called negotiable instruments / transferrable records
>    that define title to goods. The most well known is the ocean bill of
>    lading.  This thing has been stubbornly stuck in the paper world for a long
>    time because of the need for transfer of title as well as verifiability.
>    So a VC alone doesn’t cut it. Several commercial digitalisation efforts
>    have basically use some blockchain NFT for the transferability together
>    with a VC for the document integrity.  But the trouble is you simply cannot
>    depend on all parties using the same ledger (and even the same application
>    on the same ledger). So digitalisation stays niche. But what if the
>    consignment id represented by the ocean bill is a did:cel or did:webvh and
>    the cryptographic event log is use to record transfer of title?  The key
>    rotation event is also change of did controller and is the digital twin of
>    title. Assuming this could work then this is a use case where the did
>    identifies a thing not a person or an organisation. The event log and
>    reliable witnesses are fundamental features. Heartbeat not so much because
>    the did will be relatively short lived.  Also web domain doesn’t mean much
>    so a SCID based id is more relevant.
>    - Long lived assets.  Take the same idea but now apply it to vehicles
>    or even real-estate and you still need verifiability and title transfer but
>    now it’s for a long lived asset so heartbeat becomes pretty much
>    indispensable.
>    - Authoritative issuers.  What about the DIDs used by the authorities
>    listed in the GRID? They become fundamental and long lived trust anchor
>    identities. did:web alone would be risky. Also web domains start to matter
>    because there is real value in linking the web domain of the very well
>    known trust anchor to it’s did.  So did:webvh looks more attractive than
>    did:cel.
>
>
> And we can go on - the general point is that the real issue is to focus on
> the valuable collections of features and to map then to business use cases
> in a collective guidance document. It is a technical decision about whether
> it’s one did method with several testable profiles or multiple did methods
> for specific scenarios. Either way the market sees us as solving business
> problems through consensus rather than a bunch of techies arguing about
> who’s did method is better (no offence intended !).
>
> Kind regards,
>
> Steve Capell
> UN/CEFACT Vice-Chair
> steve.capell@gmail.com
> +61 410437854
>
>
>
> On 12 Jan 2026, at 3:36 am, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
> W3C CCG Chairs,
>
> We have had over a month of discussion on did:cel, and it's been 7
> days since the issue was raised[1]. Per the CCG Process, can we get a
> disposition on adoption? My read is that we have multiple people
> supporting, we have multiple co-editors, there have been concerns
> raised but no objections, and there has been a healthy discussion
> around did:cel and its relationship to other specifications that is
> ongoing.
>
> Chairs, is that enough to adopt did:cel as a W3C CCG Work Item?
>
> -- manu
>
> [1]https://github.com/w3c-ccg/community/issues/255
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>
>