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

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/