Expiry sounds simple when people explain digital identity systems. An issuer adds an end date, a verifier checks the time, and the credential is no longer valid after that. On paper, it feels clean and easy. In the real world, it rarely stays that simple.
The trouble starts when a credential moves beyond the issuer’s own system. It gets used across different apps, different chains, different trust environments, and different data layers. Some systems update quickly. Others rely on cached information. Some verifiers check status every time, while others do not. That is when a clear expiry rule starts turning into something much less reliable.
The real issue is not the signature. A credential may have been signed correctly and still be invalid today. That means verification is not only about checking whether the signature works. It is also about checking the current state of the credential. Has it expired? Has it been revoked? Has it been replaced? Has it been disputed? Those answers depend on fresh data and on whether the verifier is actually looking at the latest status instead of older stored results.
That is why @SignOfficial stands out. It does not seem to treat status like a small extra feature added later. From the way Sign describes its verification flow and status resolution, the process is about more than proving a signature is real. It is also about understanding the current condition of the credential. Expired, revoked, superseded, or disputed states are treated as important parts of the system, not rare edge cases.
This matters even more once credentials become portable. That is supposed to be the value of a system like Sign. A credential should move between different services and still be trusted. But the moment it leaves the issuer’s own environment, enforcement becomes harder. One verifier may check the live status every time. Another may refresh every hour. Another may prioritize speed and use cached data. Another may be offline for part of the day. That is how expired credentials can still get accepted. The cryptography may be fine, but the system around it is no longer perfectly aligned.
The challenge gets bigger when several issuers are involved. Different issuers can use different expiry rules, different revocation methods, and different update habits. Then the same type of credential may be checked by systems that all behave differently. One service may want real-time freshness. Another may allow a delay. Another may only do deeper checks in higher-risk cases. This is where identity infrastructure starts becoming harder to manage than people expect.
That is also why the point behind $SIGN matters. A protocol can make status visible and verifiable. It can show expiry, revocation, linked records, and the latest resolution state. That is necessary. But showing status is not the same as enforcing it. One is a design problem. The other is an operational problem spread across systems that do not always share the same standards, timing, or discipline.
Expiry may not be the most exciting part of identity infrastructure, but it reveals whether a system is built for real conditions. If a design assumes every verifier is always fresh, online, and checking the same source of truth at the same time, then it is not built for the real world. It is built for a controlled demo. Sign at least seems to understand that credential status keeps changing, and that reality has to be built into the system from the start.