I've been sitting with this specific scenario for a few days and I can't fully shake it.
A wallet gets attested through Sign. Schema checks out. Issuer signature is there. SignScan returns it clean.
The record looks exactly the way a valid record is supposed to look. Then three months later the issuer loses trusted status.
Maybe they got compromised.
Maybe the organization behind them dissolved. Maybe the credentialing authority that gave them the right to issue attestations decided their review process wasn't meeting the standard anymore.
The attestation doesn't change.
It still resolves. Still shows valid. Still carries the same visual weight in SignScan that it had the day it was issued. The downstream system checking eligibility sees a clean record and keeps moving.
That's the part I keep coming back to.
Sign's protocol preserves historical records accurately and that's genuinely correct behavior. You don't want a system that retroactively rewrites what happened. The attestation was valid when it was issued. That's true. That should stay true in the record.
But valid when issued and safe to act on now are two different sentences and most systems downstream from Sign's attestation layer aren't asking which one applies.
I traced through how this would play out in a real workflow.
A credential issued by a university gets used for access to a platform.
University's trusted status gets revoked six months later after a compliance review. The platform's eligibility filter checks for valid attestation from recognized schema family. Finds one. Clears the wallet. Never asks when the issuer's trusted status changed relative to the attestation date.
The protocol did everything correctly.
The record is accurate. The issuer status change is queryable if you know to look for it. Sign didn't hide anything.
The problem is that most systems reading Sign attestations are built to trust the visible object. Schema match.
Valid signature.
Clean record. That's the check. The secondary question of whether the authority behind the signature is still standing when the check runs doesn't make it into most integration logic because it requires a second query that most teams decide is edge-casey enough to skip.
Until it isn't.
I'm not saying Sign built this wrong. I'm saying the gap between what the attestation layer preserves and what downstream systems actually verify is wider than the clean SignScan interface implies.
The record is honest. The workflow around it usually isn't asking the right question. @SignOfficial $SIGN
