The W3C Verifiable Credentials specification turned five years old in 2024. In that time, it has gone from a promising standard to the foundation of digital identity systems on every continent. Governments are mandating it. Central banks are experimenting with it. The entire EU digital identity ecosystem is built on it.
And yet, if you take a VC issued by one implementation and try to verify it with another implementation, there is a very real chance it will fail.
I am not talking about edge cases. I am talking about basic issuance and verification flows between compliant implementations.
The Format Problem
The VC spec defines a data model (JSON-LD), but it leaves a lot of room for interpretation. Should you use JWT or JSON-LD for the credential envelope? Different ecosystems chose differently. The EU's EBSI chose JWT. Hyperledger Aries chose JSON-LD. They are both valid VC implementations. They do not interoperate.
There have been efforts to bridge this — the VC Data Integrity spec, the VC JSON Schema extensions — but the fragmentation is real. We have spent months in CREDEBL building adaptors to support both formats because our clients exist in both worlds.
The DID Method Maze
A credential references its issuer by DID. But which DID method? did:key, did:web, did:indy, did:ethr, did:cheqd, did:keri — the list keeps growing. Each method has different resolution mechanics, different trust assumptions, and different performance characteristics.
A verifier that supports did:key and did:web might not support did:indy. A wallet that resolves did:ethr might not resolve did:cheqd. The credential is valid by every spec, but the verifier cannot process it.
Universal resolver projects help, but they introduce their own latency and availability concerns. In production, you end up supporting a subset of DID methods and telling your clients to work within that set.
Revocation: Everyone Does It Differently
This might be the biggest interoperability gap. The VC spec barely touches revocation — it says credentials can be revoked, but it does not specify how. The result is a proliferation of incompatible approaches.
Some implementations use on-ledger revocation registries. Some use off-chain status lists. Some use cryptographic accumulators. Some use KERI's key event receipt mechanism. Some just do not support revocation at all.
We have built CREDEBL to support multiple revocation mechanisms, but configuring which one to use and making sure verifiers can check revocation across mechanisms is a constant challenge.
What We Are Doing About It
We participate in interop events regularly — the OIDF's VC interop testing, the W3C CCG's plugfests, and our own internal testing with partner implementations. Every event surfaces issues we did not anticipate.
We also contribute to the specifications. When we find ambiguities, we file issues. When we see patterns that work, we share them. This is not altruism — it is self-preservation. The more interoperable the ecosystem becomes, the more valuable our work on CREDEBL becomes.
The Real Talk
Interoperability in the VC ecosystem is better than it was two years ago, but it is not where it needs to be for truly seamless cross-ecosystem identity. If you are building a production system today, budget time and resources for interop testing. Assume that what works in your test environment will break in someone else's. And contribute to the standards — they get better when people like you find the rough edges.
The VC ecosystem is like the early web. The protocols work, the formats are stabilizing, but there are still compatibility quirks everywhere. Give it five more years.
Kirankalyan Kulkarni
CEO, AYANWORKS