Re: Historical status

Hi Boris, all,

First, a correction to my phone message. did:solidus records every DID
change on chain, but our resolver can't answer "what was true at time T"
yet. We're adding versionTime and versionId for that, so "we solved this"
was too strong.

I think the thread is converging. Manu's graph roll-up, bumblefudge's
notary, Boris's PAdES-LTA and UNTP's check record all say the same thing:
collect the evidence when you rely on a credential, seal it, and verify it
later without needing anyone's server. VH, CEL or a ledger are then the
places you collect it from.

Two things from the signature world may save us inventing them again. ETSI
EN 319 102-1 already has INDETERMINATE next to TOTAL-PASSED and
TOTAL-FAILED, which is Thanh's "not established". And every fact needs at
least two times: when it took effect, and when something checkable recorded
it.

A ledger's part in this is narrow: a record time the issuer can't backdate
on its own.

Rough sketch, with our own gaps listed:
https://gist.github.com/fatih-koc/9c4ab2e56a13d8f7e7a16a910096e4ad

Fatih

On Mon, Sep 28, 2026 06:51 PM, Boris Goranov <boris@ubiqu.com> wrote:

> Hi Steve,
>
>
>
> Is saw the discussion and wanted to help in the general conceptualization
> of solution options.
>
>
>
> This problem set has analogies with Qualified Electronics Signatures in
> the EU, where the problem is attacked from another angle;
>
>
>
> The core problem in the lifecycle paper* is how to prove, years later,
> what the status of a credential and its issuer was at a specific point in
> time. The proposed solution relies on historical key state, lifecycle event
> logs and point-in-time resolution.
>
>
>
> A useful analogue is the PAdES/CAdES long-term validation model, which
> approaches the same problem differently: instead of depending primarily on
> future reconstruction through historical infrastructure, it preserves the
> evidence needed to demonstrate validity at the relevant time.
>
>
>
> In PAdES-B-LT**, the signature is preserved together with the certificate
> chain and revocation evidence such as OCSP responses or CRLs. Trusted
> timestamps establish that the signature and supporting evidence existed no
> later than a specific time.
>
>
>
> Applied to the lifecycle problem in the paper, this suggests an
> alternative or complementary model: when a credential reaches an important
> lifecycle state, preserve the credential together with authoritative
> evidence of its status, issuer key state, issuer authority and relevant
> trust-registry information, and seal that evidence with a trusted
> timestamp.
>
>
>
> Long-term verification then becomes less dependent on whether the original
> resolver, status service, DID infrastructure or issuer still exists.
>
>
>
> The central design question is therefore whether the proposed historical
> lifecycle log is necessary for all long-term use cases, or whether much of
> the problem can be solved using a PAdES-LT-style preservation model based
> on collected point-in-time evidence (and optional later periodic timestamp
> renewal***).
>
>
>
> This of course means you need something like an OCSP/ CRL like structure
> in the VC context to be embedded, i am not sufficient fluent in VC
> standardization if everything needed is already there.
>
>
>
> I hope this helps.
>
> *
>
>
> https://sezoo-digital.github.io/Verifiable-Credential-Papers/LifeCycleV3.html
>
>
>
> **
>
>
> https://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.02.01_60/en_31914201v010201p.pdf
>
>
>
> ***
>
> The extension for archiving is then, PAdES-B-LTA. PAdES-B-LTA then used to
> periodically timestamps the complete validation material again, protecting
> that evidence against later expiry of certificates, disappearance of OCSP
> services or weakening of algorithms. For qualified trust services,
> historical Trusted List information provides an additional layer by showing
> whether the issuing service had the required trust status at the relevant
> time.
>
>
>
> Regards,
>
>
>
> Boris
>
>
>
>
>
> *From:* steve capell <steve.capell@gmail.com>
> *Sent:* Monday, 28 September 2026 00:43
> *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 <+61%20410%20437%20854>
>
>
>
>
>
>
>
> 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/
>
>
>