Re: Historical status

Joel, Thanh, Steve, all,

The discussion around the residual and preservation of the governing
policy gets very close to the topic which has come up on the GRID
project (https://grid.unece.org/).

However, I wonder if one distinction we need to make more explicit is
that historical observation, historical effective state, and a present
determination about historical state are not necessarily the same
proposition. For example, suppose an authority/key relationship looks
like this:

2026-04-10  credential issued
2026-05-01  key actually compromised
2026-08-12  compromise discovered
2026-08-15  authority records the compromise
2026-08-15  authority declares the compromise effective from 2026-05-01
2030-02-01  historical verification performed

A signed snapshot or notarisation taken on 2026-06-01 might perfectly
establish that the key was reported as valid at that time. It does not
necessarily establish that the key was, in retrospect, effective or
acceptable at that time once an authorised later determination has
established an earlier effective date.

So I think there are actually at least two historical questions:

1. What was recorded, published or knowable at time T?
2. What can we establish now was the effective state at time T?

Those answers can legitimately differ.

This also suggests several clocks which probably should not be
collapsed into a generic timestamp: event or decision time, effective
time, publication or record time, transaction or reliance time, and
evaluation time. There is another dimension as well. In the trade and
GRID examples we are discussing, "status" is not one thing. We may
need to reason independently about credential status, issuer or
signing-key status, authority or mandate status, and participation or
recognition within a particular trust framework or directory. A
credential could therefore remain cryptographically sound while the
historical authority proposition behind it is unknown, superseded,
retrospectively affected, or simply impossible to establish from the
surviving evidence.

So, I like the point about carrying the residual rather than reducing
the outcome to VALID / INVALID / UNKNOWN. I also noticed that Joel's
Coverage Attestation draft and, especially, the new Conformance
Continuity draft already take this considerably further by preserving
evidence provenance, baseline or version context, incomplete or
uncarried portions, and the basis on which a verdict can continue
across a boundary. What I am wondering is whether the
historical-status case introduces one more distinction: the object may
need to represent not only what was evaluated under the rules and
evidence available at the time, but also a later authoritative
determination whose effective time reaches back into that historical
period.

In that case, the object we eventually need might be a historical
determination that binds together, at minimum, the time being
evaluated, the evidence selected, the authority assertions relied
upon, the applicable policy or rule version, the checks that succeeded
or could not be completed, any later event affecting the effective
state at that time, and the resulting determination. Importantly, I
would keep that determination separate from the relying-party
decision.

The infrastructure might be able to establish:

authority state at T
key state at T
credential state at T
evidence available or missing
policy applied
later authoritative events affecting state at T

But whether the business process should then accept, reject, escalate,
or seek supplementary evidence is a governance decision for the
relying domain. This is important for GRID in particular because the
objective should not be to turn a global directory into an adjudicator
of historical commercial truth. It should be to preserve enough
authoritative history and provenance that a relying party can make an
auditable determination under its own applicable rules.

So perhaps the interoperability question is no longer simply "how do
we preserve historical status?" but:

What is the minimum interoperable representation of a historical
determination that preserves both what was knowable or established
then and what an authorised source can establish now was effective
then?

That feels complementary to the storage and history mechanisms already
discussed rather than prescribing another one.

Regards,
Sankarshan

On Mon, 28 Sept 2026 at 06:54, Joel Hillier <jhillier@certisyn.com> wrote:
>
> 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/
>
>


-- 
sankarshan mukhopadhyay
<https://about.me/sankarshan.mukhopadhyay>

Received on Monday, 28 September 2026 04:18:55 UTC