When we started building CREDEBL, we thought the hard part would be the cryptography. It was not. The hard part was everything else — operations, performance, edge cases, and the thousand small decisions that make the difference between a working prototype and a production system.
Three years and several production deployments later, here are the things that surprised us the most.
DID Resolution Is a Performance Problem
When you read the DID Core spec, resolution sounds simple: resolve a DID to a DID Document, get the public keys, verify the signature. In practice, resolution is a distributed systems problem.
The first time we ran a load test, we were resolving DIDs from a public ledger for every verification request. Each resolution took anywhere from 2 to 10 seconds depending on ledger congestion. For a system that needs to handle hundreds of verifications per second, that was a non-starter.
We ended up building a multi-layer caching strategy. DID documents are cached with short TTLs. Frequently accessed DIDs are pre-warmed. We use a local resolver with fallback to the ledger. The difference was night and day — verification times dropped from seconds to milliseconds.
The lesson: never resolve DIDs from a ledger in the hot path.
Revocation Is the Hardest Problem
Everyone who builds SSI systems eventually arrives at this conclusion. Issuance is easy. Presentation is straightforward. Revocation is where things get painful.
We started with a simple revocation list — a bitmap stored on the ledger. It worked, but every verifier had to download the entire list to check a single credential. For a system with millions of credentials, that list gets large fast.
We experimented with cryptographic accumulators (RSA and bilinear pairs). They are elegant but complex to implement correctly. We looked at status lists (W3C Bitstring Status List) which is now our preferred approach for most use cases.
The tradeoff is always the same: privacy versus performance. Private revocation mechanisms are computationally expensive. Fast revocation mechanisms leak information. There is no free lunch.
Trust Registries Matter More Than You Think
Early on, we focused almost entirely on the cryptographic layer. Signatures, keys, proofs — the stuff that looks impressive in architecture diagrams. What we learned is that the governance layer is far more important.
A verifier needs to answer a question that cryptography cannot help with: should I trust this issuer for this type of credential? That is a governance question, not a cryptographic one.
Trust registries — lists of authorized issuers and the types of credentials they are permitted to issue — are the backbone of any production SSI ecosystem. We have built trust registry support into CREDEBL and it is one of the most-used features. Every deployment customizes it differently.
What We Would Do Differently
If we were starting CREDEBL today, we would invest in better monitoring and observability from day one. DID networks are distributed systems with many moving parts — ledgers, resolvers, caches, wallets, revocation services. Without good telemetry, debugging production issues is painful.
We would also spend more time on wallet UX early on. The best credential ecosystem in the world is useless if people cannot figure out how to install and use a wallet.
Building production DID infrastructure is hard, but it is getting easier every year as the standards mature and the ecosystem grows. If you are building on DIDs today, you are early — but not too early.
Kirankalyan Kulkarni
CEO, AYANWORKS