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

Dear Steven,

Thank you for the thoughtful clarification — I fully agree with your
distinction between government control and individual choice, and
appreciate you calling that out.

To clarify my earlier wording: by “government control” I did not mean
exclusion of government or avoidance of centralized authorities. What I
intended to convey is that governments can be co-participants on the same
decentralized network, where existing hierarchical trust structures (such
as business registries, licensing authorities, etc.) can naturally operate,
while individuals and businesses retain sovereignty, safety, and the
freedom to choose when and how to engage with those services. In that
sense, decentralization becomes an enabling layer rather than a rejection
of legitimate institutions.


I also fully agree on the role separation you outlined. W3C CCG defining
the technical architecture, with organizations such as UN/CEFACT
contributing real-world business and trade use cases, feels like the right
and pragmatic path forward. In fact, I believe broader input from multiple
industries and deployment contexts is essential to aligning the DID methods
and interoperability discussions toward something that is truly
implementation-ready.


My hope is that as a community we continue to acknowledge the significant
work already done, respect the diversity of approaches, and converge
constructively toward architectures that can achieve real-world adoption at
scale. I am relatively new to this community, but I deeply respect the time
and resources many have invested, and I am always open to learning,
discussing, and collaborating wherever useful.


Kind regards,

Amir









On Mon, 19 Jan 2026 at 3:07 AM, Steve Capell <steve.capell@gmail.com> wrote:

> Hi Amir
>
> Thanks for your response
>
> I like the approach you suggest but would say that it’s the W3C CCG not
> UN/CEFACT that needs to decide how they bring these different tools into a
> consistent architecture.  Organisations like the UN can bring business use
> cases to test the technical solutions but I’m pretty sure they won’t be
> trying to write the specifications
>
> On government control, I note that there’s often an allergic reaction in
> this community whenever government or any hint of centralisation comes up.
> I think we need to be careful with language.  What decentralised
> identifiers permit is to empower the holder to choose when to leverage a
> government service rather than subject themselves to government control.
> Very different concepts.  Of course it’s government that issues drivers
> licenses or firearms permits - would you want the private sector doing
> that? It’s also government that that is the business registration authority
> and land register and so on.  Important credentials are often issued my
> centralised authorities and that’s a good thing.  What DIDs do is empower
> the individual with choice about how and when to connect these services to
> their identity.
>
> In cross border trade, linking your DID to a centrally registered
> authoritative business ID is a feature not a bug because it improves access
> to trade finance, streamline border clearance and so on.
>
> Of course there are also many scenarios where a did controller does not
> need to and would not want to go anywhere near a centralised or regulated
> service.  Thats the whole point isn’t it? Putting power back in the hands
> of the individual to make those choices.
>
> Kind regards
>
> Steven Capell
> UN/CEFACT Vice-Chair
> Mob: +61 410 437854
>
> On 18 Jan 2026, at 9:15 pm, Amir Hameed <amsaalegal@gmail.com> wrote:
>
> 
>
> 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/
>>
>>
>>