Re: Historical status

Manu, Steve

Thanks for the WebLedger links, Manu. I hadn't seen the 2016 workshop paper, and the "storing" section reads like it was written almost specifically about this thread.

Thanh already put his finger on the part I think matters most, back on 24 September, and I don't think it got picked up: "Verification may also need to preserve a result such as 'not established from the available evidence.'" I'd go further than may.

The discussion so far is mostly about preserving the evidence: notary VCs, the VH and CEL logs, Samuel's OpenID Federation subordinate-events route, Juan's audit snapshots, your graph roll-ups. All of that is about keeping the inputs alive. None of it says what the verifier is supposed to OUTPUT once the inputs are gone.

In the implementations I've looked at, "I could not determine this" collapses into the same result as "this is invalid". The issuer DID is unreachable and the answer is a negative. The context file 404s and the answer is a negative. The credential was forged and the answer is a negative. Three different states of the world, one output.

That's why the broken-link analogy doesn't carry. A broken link fails visibly, and the reader knows what they're missing. A credential whose issuer has gone fails into the same bucket as a fraud, and the relying party has no way to tell which one they are holding. Manu's 80% is fine by me. But the trouble is that nothing tells the relying party which 80% they're really in. Thanh put the same point in one line: "Missing historical evidence should not automatically be treated as proof of historical invalidity."

So the thing I'd also want specified is the residual, and as more than a third verdict value. An enumerated, signed statement of which checks could not be completed and why, carried with the determination rather than written off to a log. Thanh's "not established" tells the relying party the answer is unknown. The residual tells them which part is unknown, and that's what decides whether they can proceed anyway. It's a small amount of structure and it doesn't need anyone's server to stay up.

On the graph roll-ups. As I understand it, archiving the graph preserves the bytes. It doesn't preserve the policy that was in force when the determination was made. Replay the same bundle in 2031 against 2031 rules and you get a different answer, with nothing in the record saying the rules moved. Sealing the governing policy version into the anchor alongside the evidence is pretty cheap technically, and it's the difference between replay and re-litigation. Thanh has this in his list as something a verifier has to distinguish; I'd rather it were carried than reconstructed.

Two things I've published that bear on this specifically, offered as prior work rather than as a proposal:

    draft-hillier-coverage-attestation-00     20 Aug 2026
    draft-hillier-conformance-continuity-00   27 Sep 2026

The first specifies a withheld disposition and binds it to a digest, so "not examined" is a recorded outcome rather than an absence. The second carries a determination across a boundary where the target regime differs, and it has to deal with a target outcome against which no claim was ever made, which looks to me to be the same shape as your undefined historical period, Steve.

FYI, both are individual Informational drafts, nothing is yet adopted, and I would rather they were pulled apart than cited if that yields a better version of the outcome.

For the record, both carry BCP 79 disclosures at the IETF and Certisyn has provisional applications in this area. Anything I put up here I'll disclose the same way.

Is there appetite in CCG for a work item on the residual specifically, separate from the storage question? Thanh's closing question is close to the same ground, so it may be one work item rather than two. If there is, I'll put up a strawman built on what's already published, so there's something concrete to argue with. If the group thinks CEL or VH already covers it and I have somehow missed that, please let me know and I'll pivot.

Best,

Joel Hillier
Certisyn, Inc.
standards@certisyn.com


________________________________
From: steve capell <steve.capell@gmail.com>
Sent: Sunday, September 27, 2026 4:42 PM
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: Bumblefudge <bumblefudge@learningproof.xyz>; Credentials Community Group <public-credentials@w3.org>; Stephen Curran <swcurran@cloudcompass.ca>
Subject: Re: Historical status

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
+61 410437854



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

On Thu, Sep 24, 2026 at 5:20 AM Bumblefudge
<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/