Re: Historical status

This extension of the OpenID Federation is the one I should had linked to:
https://openid.net/specs/openid-federation-subordinate-events-1_0-ID1.html


      Samuel

From: Samuel Rinnetmäki <samuel.rinnetmaki@findy.fi>
Date: Thursday, 24. September 2026 at 14.18
To: Credentials Community Group <public-credentials@w3.org>
Subject: Re: Historical status


Hi Steve,

I’m sure you’re aware of did:webvh (https://identity.foundation/didwebvh/). It keeps track of the key history so that a verifier in 2028 can look up the keys used to sign a VC in 2026 were used by the issuer at the time. This doesn’t solve your problem, but can be a part of the solution.

One approach could be to not issue a permanent “until-revoked” accreditation VC but instead a yearly VC that the conformity body needs to re-acquire yearly. Thus, the accreditation VCs for 2026 and 2027 stay valid even if the conformity body misbehaves and its accreditation VC is revoked in 2028.

Instead of linked VCs, you could of course use a trust registry where all the changes of accreditation could be preserved. In the trust registry lookup, the verifier could ask if the conformity body was accredited to issue steel mill test certificates in 2027.

The OpenID Federation protocol doesn’t explicitly define that kind of historical query, but it the Extended Subordinate Listing Endpoint (https://openid.github.io/federation-extended-listing/main.html#name-extended-subordinate-listing) could be used to fetch information to verify that the national accreditation body had accredited the conformity body to issue steel mill test certificates in 2027.

The test certificate VC could also contain the OpenID Federation trust chain in the trust_chain JOSE header as defined in https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-jwt-proof-type

It’s a snapshot from the time of the VC issuance, but if the trust anchor (the global root of national accreditation authorities 😊) is still resolvable, the verifier can consider the trust chain having been valid at the time.

This is probably not the community consensus, but hopefully at least an indication that there are solutions we can use beyond bit string status lists.

      Samuel

From: steve capell <steve.capell@gmail.com>
Date: Thursday, 24. September 2026 at 10.29
To: Credentials Community Group <public-credentials@w3.org>
Subject: Historical status

Hello credentials community group

We at trade digitalisation projects at UN (see grid.unece.org, unvtd.unece.org, untp.unece.org) are getting significant traction with digital portable credentials for trade documents like invoices, waybills, product passport, and so on.  Also with anchoring those documents to authoritative identities from national business registers and the like.

That’s all great but we are now getting asked (and asking ourselves) to peer into the future when there are millions of trader DIDs and billions of transactional VCs.  And a key question, particularly for legal record keeping, is not so much “Is this credential valid?” But “was this credential valid when it was attached to this 5 year old transaction?”.

Specific use case (there are dozens) : a conformity body is accredited by their national authority to issue steel mill test certificates in 2026 - backed by an accreditation VC.  The body issues 1000’s of test certificates (also as VCs linked to that accreditation.  In 2028 that accreditation is revoked.  The bitstring status list now says revoked. A verifier has a batch of construction steel from 2027 with mill test certs issued in 2027.  When they verify these certs in 2028, the linked accreditation says revoked.  So the batch fails verification.  But actually it was genuinely tested when the certifier accreditation was still valid.  But there’s no way to know WHEN the status changed.

Lots more use cases around DID expiry / revocation. When verifying something in 2028 that signed by a valid did in 2026 but which was revoked in 2027 - the transaction was valid AT THE TIME OF ISSUE.  How do I know ?

If we are all successful with widespread adoption iv VCs, 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.

What’s to community consensus around solving this?

Steve Capell
Mob/whatsapp: +61 410 437854