#signdigitalsovereigninfra $SIGN been thinking about revocation & how final it sounds until you try to apply it at a distributed system 😜
I see revocation as simple as an issuer decides a credential is no longer valid, updates its status, and from that point forward it shouldn’t be accepted anywhere & rust removed 🙈
but that assumes every part of the system sees that change at the same time.
in something like @SignOfficial credentials are designed to move. they get stored in wallets, presented across platforms, verified by different services. which means the moment a credential leaves the issuer’s immediate control, revocation becomes less about decision and more about propagation.
because the issuer can revoke… but how quickly does that reality reach every verifier?
you can anchor revocation on-chain, maintain registries, require real-time checks during verification. all of that helps. but it also introduces dependencies. now every verification isn’t just checking a signature — it’s checking current status. availability matters. sync matters.
and not every verifier behaves the same way.
some might check status live every time. others might cache results. some might operate in low-connectivity environments where real-time checks aren’t always possible. in those gaps, a revoked credential can still appear valid, not because the system failed, but because the update hasn’t fully reached everywhere yet.
it gets more complex when multiple issuers are involved in $SIGN
different revocation methods, different update speeds, different assumptions about how verifiers should check status & becomes a distributed process across the network.
$SIGN can make revocation transparent and verifiable. it can define clearly when something is no longer valid. but enforcing that state everywhere, instantly, across independent systems… that’s a different challenge entirely.
I’m wondering if it becomes real to that every verifier keep checking, every time 🤔