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

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