Re: Historical status

Hello Steve, bumblefudge, all,

I want to pick up the privacy objection, because I think it decides the
shape of the answer rather than blocking it.

bumblefudge is right that publishing revocation history would leak a great
deal. But herd privacy in StatusList exists to protect natural persons from
having their credential history mined. The object in Steve's use case is
not a natural person. It is the accreditation of a conformity body: an
institutional authority that the public is entitled to check, and which in
most regimes already sits in a public register.

So the distinction I would put to the group is this.

1. Authority state, meaning issuer DIDs, accreditations, licences and
registrations, can carry public, timestamped lifecycle history at no
privacy cost, because the authority is public by construction.

2. Personal credential state must keep herd privacy, and its status should
remain a bitstring whose history nobody can reconstruct.

Steel mill test certificates fail today because the ecosystem applies the
second model to the first kind of object. The fix is not to weaken
StatusList. It is to stop treating an accreditation as if it were a
person's credential.

Concretely, a verifier asking "was this valid at time T" needs three facts:

a. the issuer's DID document as it stood at T,
b. the authority's status at T,
c. evidence that the credential existed at T.

(a) and (b) are answerable by any method that records transitions in an
ordered, timestamped, tamper evident log and exposes them for resolution.
(c) is what bumblefudge's notarisation receipt provides, and the two
compose cleanly: the receipt pins the credential to a time, the authority
log says what was true at that time.

On our own position, so nobody has to guess. did:solidus records DID
creation, update and deactivation as distinct transactions on a BFT chain
with roughly one second blocks and single block deterministic finality, so
the transitions are already ordered and timestamped. What we do not do
today is expose them: our method specification says plainly that there is
no historical resolution and that nextVersionId and previousVersionId are
unset. The data answers the question and the interface does not, which is a
gap on our side and one we are closing with versionTime and versionId
resolution.

Two questions I would genuinely like the group's view on:

Is a public, versioned log appropriate for accreditation state
specifically, or does anyone see a leak I am missing when the subject is an
institution rather than a person?

And for (c), is periodic notarisation the consensus direction, or should
issuance itself carry a timestamp anchor so the holder does not depend on a
notary being available years later?

Best regards,

Fatih Koçkesen
Solidus Network

On Thu, Sep 24, 2026 10:31 AM, steve capell <steve.capell@gmail.com> wrote:

> 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 <+61%20410%20437%20854>
>