Re: Supply Chain Cryptographic Event Logs (was Re: [PROPOSED WORK ITEM] CEL DID Method (did:cel))

Hi all,


Building on the ongoing discussion, I’d like to suggest one practical way
to evaluate how did:cel could be leveraged for cross-border markets.

Before optimizing the method itself, it may be useful to first model the
full lifecycle of a user (or organization) and how they interact with the
network over time:


   -

   onboarding and identifier creation
   -

   credential issuance and updates
   -

   transactional interactions
   -

   recurring vs. high-value interactions
   -

   dispute, recovery, and revocation scenarios

From there, we can compare:


   -

   how these flows are handled today with existing technologies, and
   -

   how a forward-looking DID:CEL-based approach would differ in terms of
   trust, cost, latency, and resilience.

In parallel, I believe we should explicitly consider the nature of
interactions:


   -

   size and frequency of transactions
   -

   different use-case categories
   -

   critical vs. high-risk profiles
   -

   regulatory and cross-jurisdictional constraints


This leads to a more general architectural point.

It may be valuable to define a general, implementation-agnostic data
structure that serves two complementary purposes:


   1.

   a format for transactional events, and
   2.

   a format for structured data exchanged back and forth between parties.


The idea would be that did:cel provides a universal causal / event
structure in which both identity events and data events can coexist, on top
of the systems already being built.

For example, if a user in India interacts with a counterparty in another
country, it is not only the identifier that benefits from standardization,
but also the event and data model itself — which could be:


   -

   linked to existing DID and VC standards,
   -

   extensible via use-case-specific metadata, and
   -

   protected using signatures and TTL / validity constraints.


At the infrastructure level, this same structure could also be treated as a
network primitive.

In such a model:


   -

   witness registries can act as high-reliability nodes,
   -

   participating in gossip-style propagation of events,
   -

   performing Byzantine-fault-tolerant verification, and
   -

   replicating validated event/data objects across multiple trusted
   registries in a chained or federated manner.

This would allow the same signed event objects to be:


   -

   verified once,
   -

   witnessed by diverse parties, and
   -

   consistently replicated across independent trust domains,


while remaining compatible with different resolution and deployment models.

Overall, this would allow DID:CEL to function as a common structural layer
for cross-border digital interactions — spanning identity, data, and
network-level trust — without constraining specific implementations or
centralizing control.

Happy to explore this further if the group finds the direction useful.


Best regards,

Amir


On Tue, 20 Jan 2026 at 3:37 PM, Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> Lastly (for today), Virtual DIDs w/VH is a key enabler for the SSC 7.0
> Metamodel and Tim Bouma's concept of a Beneficial Controller:
> https://hyperonomy.com/2025/12/10/self-sovereign-control-ssc-7-0-metamodel/
>
> Michael Herman
> Chief Digital Architect
> Web 7.0 Foundation
>
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Sent:* Tuesday, January 20, 2026 10:57:18 AM
> *To:* steve capell <steve.capell@gmail.com>
>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG <
> public-credentials@w3.org>
> *Subject:* Re: Supply Chain Cryptographic Event Logs (was Re: [PROPOSED
> WORK ITEM] CEL DID Method (did:cel))
>
> After sleeping on the subject of Virtual DIDs overnight, I like them more
> and more. Simple, straight forward, easy to explain, based on existing
> standards, no magic ... implementable with or without a VH.
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* steve capell <steve.capell@gmail.com>
> *Sent:* Tuesday, January 20, 2026 5:05:26 AM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG <
> public-credentials@w3.org>
> *Subject:* Re: Supply Chain Cryptographic Event Logs (was Re: [PROPOSED
> WORK ITEM] CEL DID Method (did:cel))
>
> Getting there ;)
>
> At least we are now talking about the same problem - cryptographically
> verifying transfer of title to a *thing* (not a person or org) with a
> pure protocol based approach with no dependency on specific platforms.  As
> Manu stated and you have hinted, the key idea is to use witnessed
> cryptographic event logs - whether bound to a did:cel or did:webvh, or
> did:keri or not a did at all is a secondary implementation question.
> Personally I like the idea of binding to did because the thing being
> transferred has to have a unique id that survives the transfer.  The
> did:cel doesn’t change when the underlying key controller changes via a key
> rotation event.  If we don't think of this event only as “iv’e rotated my
> key” but also as “I’ve given someone else control of the new key” then it
> mimics the real world pretty well.
>
> Not only for MLETR transferrable records.  Also for book & claim chain of
> custody tokens (think transferrable carbon credits) and even
> anti-counterfeiting.  Lots of use cases might boil down to different state
> lifecycles of the did:cel that is attached to the physical thing.
>
> Steve Capell
> UN/CEFACT Vice-Chair
> steve.capell@gmail.com
> +61 410437854
>
>
>
> On 20 Jan 2026, at 2:54 pm, Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
> New idea: Virtual DIDs
> Using something like https://www.w3.org/TR/did-1.1/#equivalence-properties in
> the DID Document to essentially create a DID redirection.
> Tracking these types of changes with a VH would be an interesting approach.
>
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* steve capell <steve.capell@gmail.com>
> *Sent:* Tuesday, January 20, 2026 4:46:22 AM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG <
> public-credentials@w3.org>
> *Subject:* Re: Supply Chain Cryptographic Event Logs (was Re: [PROPOSED
> WORK ITEM] CEL DID Method (did:cel))
>
> No changing the value, changing who has control.  We normally thing of
> did:cel as a way for a single person or org to manage things like key
> rotations or even (with did:webvh) transfer between domain hosts.  But the
> event log already has the idea of current key control being passed to next
> key control in a verifiable witnessed way.  Just instead of rotating keys
> for the same party, the proposal is to transfer key control across
> parties.
>
> Steve Capell
> UN/CEFACT Vice-Chair
> steve.capell@gmail.com
> +61 410437854
>
>
>
> On 20 Jan 2026, at 2:43 pm, Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
> RE: the did:cel of the consignment which is the Credentialsubject of the
> BoL, not the issuer. Transferring control of the consignment did (not the
> carrier did) seems achievable with the event log.
>
> This sounds like one is trying to use a VH to surgically change the value
> of the credentialsubject.id in an existing VC?
>
> Is this possible Many?
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* steve capell <steve.capell@gmail.com>
> *Sent:* Tuesday, January 20, 2026 4:38:15 AM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG <
> public-credentials@w3.org>
> *Subject:* Re: Supply Chain Cryptographic Event Logs (was Re: [PROPOSED
> WORK ITEM] CEL DID Method (did:cel))
>
> Well, first acknowledging that this is a thought experiment and could be
> wrong, I think the answer may be to clearly separate two things:
>
>
>    - the did:cel of the carrier that issues the BoL VC - that cannot be
>    transferred because of course it identifies the carrier not the consignment.
>    - the did:cel of the consignment which is the *Credentialsubject* of
>    the BoL, not the issuer.  Transferring control of the consignment did (not
>    the carrier did) seems achievable with the event log.
>
>
> Regards,
>
> Steve Capell
> UN/CEFACT Vice-Chair
> steve.capell@gmail.com
> +61 410437854
>
>
>
> On 20 Jan 2026, at 2:27 pm, Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
> RE: https://chatgpt.com/s/t_696ef188bd6c8191b902a5d0ebc44791
>
> The next step (using option 3) is the really interesting one: how do you
> change the controller DID? ... presumably, the controller DID in the BOL
> VC... which the BOL VC itself isn't supposed to change. If/how can a VH
> solve this? I don't think it can?
> Option 3: https://chatgpt.com/s/t_696ef4a830fc8191a7e767a86a4b6c51
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* Steve Capell <steve.capell@gmail.com>
> *Sent:* Tuesday, January 20, 2026 4:09:01 AM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG <
> public-credentials@w3.org>
> *Subject:* Re: Supply Chain Cryptographic Event Logs (was Re: [PROPOSED
> WORK ITEM] CEL DID Method (did:cel))
>
> Here’s a ChatGPT conversation that highlights the issue
> https://chatgpt.com/s/t_696ef188bd6c8191b902a5d0ebc44791
>
> This is the rationale behind international model law from un/citral on
> transferable records (Google MLETR)
>
> Steven Capell
> UN/CEFACT Vice-Chair
> Mob: +61 410 437854
>
> On 20 Jan 2026, at 1:55 pm, Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
> 
> A BOL is a 2-party contract between a consignee and a shipper. It can be
> easily represented as a VC with a 2 x proof proof-set. Once the shipment is
> consigned, it doesn't change.
> Reference:
> https://www.maersk.com/support/faqs/two-purposes-does-a-bill-of-lading-serve
>
> If you want to track delivery status and/or delivery confirmation, those
> are different documents (different VCs, typically single party).
>
>
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* steve capell <steve.capell@gmail.com>
> *Sent:* Tuesday, January 20, 2026 12:14:19 AM
> *To:* Manu Sporny <msporny@digitalbazaar.com>
> *Cc:* W3C Credentials CG <public-credentials@w3.org>
> *Subject:* Re: Supply Chain Cryptographic Event Logs (was Re: [PROPOSED
> WORK ITEM] CEL DID Method (did:cel))
>
> Hi Manu,
>
> Thanks for this assessment.  We could be thinking the same thing.
>
> I didn’t mean that the did:cel would contain the entire bill of lading.
> Assumed that would be a VC.  I assumed that the issuer of the VC is the
> original carrier.  The subject of the vc is the consignment identified by a
> did:cel.  And so the transfer of control is achieved by transferring the
> underlying did:cel consignment ID to a new controller (aka title owner).
> So verification is “yes it’s a valid BoL and issued by a known and trusted
> ocean carrier, I see that the Consignment id is also represented as a
> did:cel, now who currently controls that did:cel because that are also the
> current title holder”.   Is that more or less what you were thinking or am
> I off track?
>
> Steve Capell
> UN/CEFACT Vice-Chair
> steve.capell@gmail.com
> +61 410437854
>
>
>
> On 20 Jan 2026, at 9:42 am, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
> On Sat, Jan 17, 2026 at 9:05 PM steve capell <steve.capell@gmail.com>
> wrote:
>
> Transferrable records.
>
>
> I'm not sure the core of that flow is a did:cel or a did:webvh use
> case -- it could be a VC use case where the bill of lading has a
> controller that is set at every step of the journey by the previous
> controller... where the changes to each re-issued VC are wrapped up in
> a Cryptographic Event Log (CEL). So, you could punt the NFT and
> blockchain network to the curb and just depend on raw/dumb
> HTTPS-accessible storage to "hold" the latest version of the bill of
> lading.
>
> Don't get me wrong, you could model the ocean bill of lading as a DID
> Document, where transfer of ownership is done via key rotation or
> something like that. That's one of the benefits of Linked Data -- you
> can embed graphs of information just about anywhere. That is also one
> of the drawbacks -- you have many ways that information can be
> modelled and we depend on a body like UN/CEFACT to tell us all how to
> do it.
>
> So, this could look something like:
>
> 1. Original bill of lading (BOL) is issued by the Shipper. BOL becomes
> the first entry in cryptographic event log with Shipper as controller.
> 2. Shipper transfers cargo to Carrier. Shipper sets Carrier as
> controller and digitally signs VC. Updated BOL becomes second entry in
> cryptographic event log with Carrier as controller.
> 3. Shipper shares latest BOL in cryptographic event log with Bank,
> bank releases payment to Shipper. Shipper sets Bank as controller and
> digitally signs VC. Updated BOL becomes third entry in cryptographic
> event log with Bank as controller.
>
> I probably messed something up in the steps there (you are the expert
> here, not I), but I hope you get the gist of how it might work with a
> cryptographic event log. The DIDs would be the long-term identifiers
> for the entities (Shipper, Carrier, Bank, etc.) -- those could be
> did:web, did:webvh, did:cel, doesn't matter as long as they meet the
> needs of the ecosystem. Digital signatures to "transfer ownership"
> would be based on keys associated with each controller's DID.
>
> Long lived assets.
>
>
> Yes, we are looking at CELs for this, and they'd mirror the sort of
> thing going on with BOL above (except simpler -- usually just
> buyer-seller transfers are recorded in the CEL over time).
>
> Authoritative issuers.
>
>
> CELs may or may not play a role here -- you can combine DIDs with VCs
> and CELs to get to multiple variations of what you're talking about
> that work without the need for a blockchain (since you noted that
> blockchain adoption is difficult in the supply chain space).
>
> 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 !).
>
>
> Yes, agreed.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>
>
>
>
>