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

ne 18. 1. 2026 v 22:40 odesílatel Steve Capell <steve.capell@gmail.com>
napsal:

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

Hi Steve/Manu,

Your transferable records use case caught my attention, especially the
framing of key rotation as title transfer.

I've been working on something in a similar direction called Blocktrails
(early-stage):

https://blocktrails.org/

The core idea is to anchor evolving state to Bitcoin using chained Taproot
key tweaks, where each state transition is a P2TR spend. That gives a
strong anti-fork property: the UTXO model enforces a single history (you
can’t "double-spend" title), with witnessing provided by Bitcoin
consensus/miners rather than a separate witness network, using existing
Bitcoin primitives today.

Applied to bills of lading: title transfer = spending to the new holder’s
key. You get an on-chain, globally verifiable transfer with practical
finality after standard Bitcoin confirmations.

It’s also secp256k1-key aligned (and therefore naturally compatible with
did:nostr). Different trade-off than did:cel (Bitcoin fees vs. witness
infrastructure), but potentially complementary for higher-value
transferable records.

I'm also actively working on key rotation flows with hardware wallet
integration, so that title transfer and custody changes can be executed
using existing HSM / hardware wallet security models.

Happy to discuss if it's useful.

Melvin


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