Re: Historical status

Hi folks,

Thanks, this is a good discussion.

However, can I remind folks to please be respectful in their AI use while
participating in CCG conversations.

Some of the responses appear to be almost entirely AI generated, long
winded and time-consuming to parse.
This is not the best way to collaborate with the community, do not be
surprised if your email gets overlooked by others in this thead.

This W3C Note on the use of LLMs is worth reading through
https://www.w3.org/TR/2026/NOTE-llms-standards-20260324/

Thanks,
Will Abramson
On Behalf of CCG Chairs

On Mon, Sep 28, 2026 at 7:28 AM Joel Hillier <jhillier@certisyn.com> wrote:

> Sankarshan, Steve, all
>
> Sankarshan, that's the gap and I hadn't seen it. Thanks for pointing me to
> it.
>
> I have since gone and checked rather than claim it was covered. My
> draft-hillier-conformance-continuity-00 carries supersedes and
> superseded_by, but only as relationships an issuer states between
> baselines, and the one place it uses "retroactive" is a threat-model entry
> about an adversary backdating a record.
>
> There is nothing in it for an authorised later event whose effective time
> reaches back into a period already determined. I reckon your example breaks
> it cleanly. A determination sealed in June 2026 is correct about what was
> knowable and says nothing at all about what the August declaration made
> effective in May. So "historical observation, historical effective state,
> and a present determination about historical state are not necessarily the
> same proposition" is the sentence I'd put at the top of the work item, and
> the clocks you name - event or decision, effective, publication or record,
> transaction or reliance, evaluation - are the fix. I'd take them as named.
> Both my drafts collapse to a collection timestamp, which is fine while the
> only question is when the evidence was gathered, and useless the moment an
> effective date starts moving independently of a record date.
>
> I think it belongs in the same object rather than a second one. The
> residual says which checks could not be completed and why. Yours says as of
> when, and what has since displaced it. A determination carrying only the
> first tells a relying party about its gaps and nothing about its own shelf
> life, and it will read as complete when it is not.
>
> On keeping the determination separate from the relying-party decision,
> agreed, and that's how both drafts are built. The determination states the
> outcome and the residual. What the governing process then does about a "not
> established" is not the verifier's to say, and your line about not turning
> a global directory into an adjudicator of historical commercial truth is
> worth keeping in whatever text comes out of this.
>
> Steffen, your point that "we do not speak about the internet here but
> authoritative records in legal processes" is what kills the broken-link
> analogy properly, and better than the way I put it. A trust registry does
> preserve the chain, and it is also a server that has to stay up for as long
> as the record is relied on. Fatih's "there is no universally
> accepted ledger" is the same problem one layer down. Neither of those is
> an argument against either approach and I'd keep both. The residual is what
> the determination still says in 2030 when the registry and the ledger have
> gone.
>
> So one work item, not two, and Sankarshan's question is obviously now the
> charter sentence:
>
> 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?
>
> I'm still offering to put up a strawman built on what's already published,
> with the clocks and the retroactive-effect case in it, so there's something
> concrete to pull apart. Sankarshan, is GRID the right place to test it
> against real cases, or would you rather it stayed here until it has a shape
> worth taking there?
>
> Best,
>
> Joel Hillier
> Certisyn, Inc.
> standards@certisyn.com
> ------------------------------
> *From:* sankarshan <sankarshan.mukhopadhyay@gmail.com>
> *Sent:* Sunday, September 27, 2026 10:18 PM
> *To:* public-credentials <public-credentials@w3.org>
> *Subject:* 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 <+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/
> >
> >
>
>
> --
> sankarshan mukhopadhyay
> <https://about.me/sankarshan.mukhopadhyay>
>
>