I kept assuming credential systems fail when verification fails.
Turns out they can verify correctly… and still not work.
But the more I looked at how these systems behave in practice, the failure doesn’t start there. It starts earlier, and it’s harder to notice.
Most credentials don’t fail because they are invalid. They fail because they don’t carry the same meaning once they leave the system that created them. That part is uncomfortable because everything can look correct on the surface. Signature verifies, issuer is known, schema matches. Still doesn’t work.
The issue sits in how the credential was issued and how it is presented.
Issuance is usually treated like a simple step. Create, sign, deliver. But that’s where the system fixes what the credential actually represents. If two issuers follow slightly different logic, even if they use the same schema, the output is not really the same. One might bind identity tightly, another might allow flexibility, another might skip certain checks. The credential looks identical, but the assumptions behind it are different.
Now the verifier is not just verifying a claim. It is trying to understand how that claim came into existence. That’s where systems start adding their own interpretation layers.
Presentation creates a similar problem from the other side. It’s often described as sharing a credential, but it’s really about controlling what is revealed and how. If that logic is not consistent, the same credential can be presented in different ways across systems. One reveals full data, another uses partial disclosure, another wraps it in a proof. The receiving system now has to decide what version it trusts.
I’ve seen simple cases where a credential verifies correctly and still gets rejected. Not because it is wrong, but because the system receiving it doesn’t trust how it was issued or doesn’t accept how it is presented.
At scale, this doesn’t create small errors.
It creates systems that simply stop trusting each other.
Without standardized issuance and presentation, every system rebuilds this layer on its own. Different APIs, different assumptions, different constraints. It works locally, but the moment you try to connect systems, it turns into mapping and translation.
That’s where OIDC4VCI and OIDC4VP come in. Not as features, but as constraints on behavior. They reduce how much freedom systems have in issuing and presenting credentials. That sounds limiting, but without that limitation, systems drift apart very quickly.
Now bring SIGN into this.
SIGN fixes the meaning of the claim through schemas and attestations. It makes sure that when something is issued, its meaning is clear and verifiable across systems.
But meaning alone doesn’t travel.
If the flow carrying it isn’t constrained, it changes along the way.
If issuance is inconsistent, the same schema can produce different outcomes. If presentation is inconsistent, the same attestation can be interpreted differently depending on how it is shown.
So even with strong schema design, the system can still break at the edges.
That’s why this stack matters more than it looks. SIGN handles meaning, but OIDC flows handle how that meaning is created and moved. If those parts don’t align, interoperability turns into constant adjustment between systems.
Credential systems don’t fail because verification is weak.
They fail because trust is never standardized at creation…
and never preserved as it moves.
