AW: Historical status

Hi all,

thanks Steve for bringing up this matter. Fully agree that the history needed for fulfilling burden of proof requirements in cases you mentioned. The advice that “web of broken links” does not help since we do not speak about the internet here but authoritative records in legal processes.

Practically it means that the trust chain needs to be kept – which a Trust registry could solve.

Von: steve capell <steve.capell@gmail.com>
Gesendet: Montag, 28. September 2026 00:43
An: Manu Sporny <msporny@digitalbazaar.com>
Cc: Bumblefudge <bumblefudge@learningproof.xyz>; Credentials Community Group <public-credentials@w3.org>; Stephen Curran <swcurran@cloudcompass.ca>
Betreff: Re: Historical status


Caution: This email originated from outside of the organization. Despite an upstream security check of attachments and links by Microsoft Defender for Office, a residual risk always remains. Only open attachments and links from known and trusted senders.
Hi Manu

Thank you for taking the time to comment on this thread - I know you’ve a hundred other things on your plate.  I agree we should keep things as simple as possible (but no simpler) - and that the verifiable history need does not apply to every use case.

The broken links analogy has its limits and probably wasn’t a good choice for this problem. Yes the web allows broken links and it fixes itself quite nicely - that’s because the publisher of a page with broken links can hit the edit button and fix their own broken links.  Not so the holder of a credential that no longer verifies because the issuer DID has gone AWOL or the context file has disappeared, or (this topic) it refers to an undefined historical period.  Unlike the broken link analogy, this problem doesn't seem to have a self-correcting mechanism and so will likely just get worse and worse over time.


  *   I dont think the general problem of credential resilience is limited to supply chain.  Degree certificates, birth certificates, and many other credential types last a lifetime - Buch longer than most supply chain transaction record retention periods.
  *   Nor is the problem if historical status limited to supply chain.  An employment history for example. When a delegate issued a credential on behalf of a business, were they an authorised employee at the time?

I’m not so sure we can or should be thinking of this as an edge case.

Steve Capell
UN/CEFACT Vice-Chair
steve.capell@gmail.com<mailto:steve.capell@gmail.com>
+61 410437854




On 27 Sep 2026, at 3:56 am, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:

On Thu, Sep 24, 2026 at 5:20 AM Bumblefudge
<bumblefudge@learningproof.xyz<mailto:bumblefudge@learningproof.xyz>> wrote:

Another holder-side option is to have valid VCs periodically "notarized" by a trusted authority that hands back to the holder of the original valid VC an additional VC stating basically nothing more than "at timestamp X, you showed me a VC of `id`` Y that was valid and non-revoked at the time", which the holder can share as needed.

Good discussion thread so far, lots of good stuff added by Giampiero,
Thanh, Stephen, Steve, and Fatih. I wanted to highlight a few things:

There is a real risk here of over-optimising for the supply chain use
case and making the entire ecosystem far more complicated than it
needs to be. Sometimes all you need is an ephemeral transaction.
Sometimes you don't want all of your actions recorded.

Of the solutions provided, I tend to agree that Bumblefudge's approach
is the cleanest... not everything needs an audit trail, so only do
that for the things that require it, and a trusted notary is a simple
and straightforward way to do that. If you need an audit trail, there
is an auditor, and if there is an auditor, there is likely a regulator
-- put the onus on them to provide an automated notary service. The
input is a VP, the output is all of the checks that succeeded/failed,
possibly as an audit certificate of some kind. This is not a difficult
system to build, but it is regulatory-framework specific.

Presuming that all these organizations and entities are going to keep
their servers up over long periods of time is a bad assumption, IMHO.
Organizations come and go, and so does their infrastructure. Steve
said something interesting in his initial opening, which was:


it feels like we are heading for a horrendous resilience problem a few years down the road when we don’t know the verifiable history of legal records.  Like a web full of broken links.

... but a "web full of broken links" is exactly why the Web won over
every other hyperlink information system at the time. The Web's design
explicitly stated: It is ok to have broken links. I know it seems
really obvious these days, but at the time, most every other hyperlink
information system was trying to ensure bi-directional link
correctness across the entire system (this is why all of those systems
failed, it doesn't scale).

All that to say, I think it's okay if 80% of these things are "broken
links" in the future, as long as it's not the wrong 80%. Historical
status is an important feature /for the systems that need it/, so a
big +1 to work on the problem. I agree with Stephen that both the
did:webvh log and the CCG's CEL spec (and did:cel) have been working
on the solution for a while. I'll also point out a long forgotten
specification from CCG (way back from 2016), WebLedger, that did the
same thing:

https://www.w3.org/2016/04/blockchain-workshop/interest/sporny-longley.html

https://w3c.github.io/web-ledger/


Steve, you'll note things like "real estate transaction" and "loan
transfer" (inspired by the global financial meltdown) that will look
familiar to you, from over a decade ago:

https://w3c.github.io/web-ledger/#storing


... and, of course, Bitcoin and Ethereum predated that... and what
came out of some of that work was W3C DIDs, VCs, and Data Integrity
(among other technologies, like CEL)... after much input from this
community and others.

All that to say, "Historical status" is something CCG has been
discussing for many years, we thought blockchains were going to solve
that problem for us... until they didn't (really)... and now we're on
to things like VH and CEL (and KELs and TELs), but I'm not convinced
that those are going to be the solution to the problem you state,
either.

If I had to bet, it would be some variation of what Juan suggested
(audit snapshots as a VC) or graph roll-ups (where you just roll up
the entire graph relevant to the VP in a bundle for archival -- that
means, all relevant DID Documents, VCs, and resources linked to within
the graph are bundled and archived together such that you can run any
future query on the graph at that point in time -- this is just a
glorified ZIP file containing all the VCs and files linked to in the
graph of VCs).

Just some thoughts -- wonder if we're overthinking this... simpler is
usually better.

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/

Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/