@SignOfficial $SIGN #SignDigitalSovereignInfra

I was reading the Sign Protocol docs and the part I kept circling wasn’t the signing part, honestly. It was the way verification is described as a stack instead of one clean yes/no moment. The docs break it out very plainly: schema verification, signature verification, authority verification, status verification, evidence verification. Which sounds neat when you first read it, almost reassuring. Like, okay, the system already knows how to keep truth clean. But the second I saw status verification sitting there as its own separate step, my brain went somewhere much less tidy.

Because that means the attestation itself does not magically stop being a valid-looking object just because something changed upstream.

And the docs basically admit that in a very calm, infrastructure way. They say an attestation is meaningful relative to who signed it, what authority they had, what schema it conforms to, and how revocation and updates are handled. That “how revocation and updates are handled” part is doing a lot of work. It means revocation is not the same thing as deletion. It means a record can still exist, still parse, still carry a real signature, still look structurally fine, while its live status has already shifted somewhere else.

That is the part I can’t stop poking at.

Because if I issue a credential, then later revoke the identity status that used to support it, I kind of want the whole downstream world to behave like the old thing is dead now. Psychologically, that is what “revoked” sounds like. Emergency cutoff. Finished. Do not trust this anymore. But that is not actually what the Sign docs describe. What they describe is a system where attestations are treated as append-only records, and when something changes you do not mutate history into disappearing. You revoke, supersede, dispute, or attach corrections under rules. So the older object is still there. History stays legible. Which is good for audit, but kind of brutal for lazy consumers.

And that is where the real pressure shows up for me.

Not revocation failure. Revocation drift.

The issuer can update status correctly. The governance model can say this credential is no longer acceptable. But if some downstream workflow is mostly checking signature and schema and only vaguely assuming currentness, the older attestation can keep circulating as a perfectly well-formed piece of evidence. Not because Sign is broken. Because the workflow stopped early. The docs are actually pretty explicit that status verification is part of verification, not some optional extra for careful people. So the edge case is not “what if revocation doesn’t work.” The edge case is “what if the record keeps moving faster than the status check.”

That is why this feels so native to Sign Protocol and not like some generic credential complaint.

Sign is built to preserve structured claims so they can be inspected later. That is one of its strengths. But once you preserve claims this well, you also preserve the possibility that somebody downstream will encounter an older valid artifact and treat it like current truth unless they re-run the full verification context the docs are telling them to run. The protocol preserves evidence. It does not rescue every integrator from shallow reading.

So yeah, after reading the docs, the thing I would say out loud is basically this:

revocation in Sign Protocol does not erase the record. It changes the interpretation conditions around the record. And if the downstream system does not keep checking those conditions, the old attestation can keep walking around with a green-check aura long after the live identity state has already moved on.

That is not a dramatic exploit.

It is worse, in a very boring institutional way.

It is a systems-reading problem.