Where decentralised identity's generality becomes a cost
The standard solves a hard problem: verifying a credential from an issuer you have no relationship with, whose identifiers you resolve through infrastructure neither of you controls. Most enterprise flows do not have that problem.
When are W3C Verifiable Credentials the wrong tool?
When the issuer is already known. The W3C stack buys verification between parties with no prior relationship: DID resolution, method plurality, multiple proof suites. An enterprise verifying its own approval records has a known issuer and published keys, so it pays the complexity and receives none of the benefit.
- The stack's complexity buys issuer-agnostic verification without prior relationship, which is genuinely valuable in open ecosystems.
- Enterprise flows usually have a known issuer, so resolution infrastructure and method plurality add cost without benefit.
- A simpler receipt with a published key covers the closed case; the standards stack remains right for the open one.
Part of Category comparisons
What the stack provides
The design goal is verification without coordination. A verifier encountering a credential from an unknown issuer can resolve the issuer's identifier, obtain their keys and check the signature — without any prior relationship or shared registry.
That is a real achievement and it enables things a closed design cannot: cross-border credentials, credentials from issuers you have never heard of, ecosystems with no central authority.
What it costs
| Layer | Purpose | Cost in a closed deployment |
|---|---|---|
| Identifier method | Decentralised issuer identifiers | Method plurality — dozens of methods, varying support |
| Resolution | Turning an identifier into a key document | A network dependency and an availability question |
| Data model | Expressing claims generically | Processing that a fixed schema does not need |
| Proof formats | Multiple signature suites | Implementation surface and negotiation |
| Revocation | Status lists and mechanisms | A further fetch |
In an open ecosystem each column two entry justifies its column three cost. In an enterprise flow with one known issuer, the costs remain and the benefits do not arise.
The closed case, concretely
A company's own approval records. The issuer is the company. The verifiers are the company, its auditors and its regulators. Nobody needs to discover an unknown issuer's keys.
# What the closed case actually needs
issuer: known, one of them
keys: published at a well-known URL, fetched and cached
format: one schema, one algorithm
proof: one signature over a canonical statement
# What resolution infrastructure adds here
a way to discover keys you already know
a network dependency where you had none
method negotiation for a single issuerThe complexity is not wasted in general; it is wasted here, because the problem it solves does not exist in this deployment.
The latency point, in proportion
Resolution adds a fetch, which for a cached key document is not a per-verification cost. The performance argument is real for cold paths and is often overstated.
The more durable argument is the dependency rather than the milliseconds. A verification path that can require a network resolution is a verification path that can fail for network reasons, and for evidence that matters years later that is a liability.
Choosing between them
| Situation | Appropriate |
|---|---|
| Credentials from issuers you have no relationship with | Verifiable credentials |
| Cross-organisation, cross-border ecosystems | Verifiable credentials |
| Individuals holding portable credentials from many issuers | Verifiable credentials |
| Your own approval records for your own audit | A simple signed receipt |
| Records that must verify unchanged for a decade | A simple signed receipt |
| A closed set of known counterparties | Either — choose on ecosystem alignment |
The last row is where a deliberate decision is needed. If your counterparties already use the standards stack, aligning with them may be worth the complexity even for a closed flow.
Interoperating rather than choosing sides
These are not mutually exclusive. A receipt can be expressed as a credential in the standard data model for parties who expect that, while the underlying statement and signature remain simple.
That is the pragmatic path: keep the record format minimal so it survives decades, and present it in whatever envelope a given counterparty requires. The envelope is a serialisation question; the evidence is what it contains.
What each layer costs in a closed deployment
| Layer | Purpose | Cost when the issuer is known |
|---|---|---|
| Identifier method | Decentralised issuer identifiers | Method plurality with varying support |
| Resolution | Turning an identifier into keys | A network dependency you did not have |
| Data model | Expressing arbitrary claims | Processing a fixed schema does not need |
| Proof formats | Multiple signature suites | Implementation surface and negotiation |
| Status lists | Revocation | A further fetch |
The durable argument is the dependency rather than the milliseconds. Cached key documents make the per-verification cost small, but a verification path that can require a network resolution is one that can fail for network reasons — and for evidence that must hold for a decade that is a liability.
Objections and honest limits
“So the standard is over-engineered.” Not for what it was designed for. Verifying a credential from an issuer you have never heard of, without shared infrastructure, is genuinely hard and the stack solves it. The complexity is wasted only where that problem does not exist.
“Our counterparties already use it.” Then aligning may be worth the complexity even for a closed flow. Keep the underlying statement and signature minimal and present it inside a credential envelope — the envelope is serialisation, the evidence is what it contains.
Choosing the right envelope
- Is the issuer known in advance? If yes, resolution infrastructure is solving a problem you do not have.
- Must this verify in ten years? Then minimise moving parts and publish keys durably.
- Do counterparties expect a specific format? Alignment can outweigh simplicity; wrap rather than rebuild.
- Can a sceptical party reimplement your verifier? If not, the evidence depends on your tooling rather than on the format.
Terms used here
- DID
- Decentralized Identifier: an identifier that resolves to a key document through a method-specific mechanism, without a central registry.
- Proof suite
- The cryptographic scheme securing a credential. Plurality is a feature in open ecosystems and implementation surface everywhere else.
- Envelope
- The serialisation wrapping a signed statement. Changing it does not change what the evidence says.
Frequently asked questions
Are verifiable credentials over-engineered? Not for what they were designed for — verification between parties with no prior relationship. The complexity is wasted only where that problem does not exist.
What does an enterprise approval record actually need? A known issuer, keys published at a stable location, one schema, one algorithm and one signature over a canonical statement.
Is the latency argument decisive? Not really. Cached key documents make the per-verification cost small. The stronger argument is the network dependency for evidence that must verify years later.
Can both be used? Yes. Keep the record format minimal and present it inside a credential envelope for counterparties who expect that. The envelope is serialisation; the evidence is the content.
Where this fits in Manav
Manav's receipt is deliberately small: one canonicalisation, one algorithm, keys at a well-known URL, a verifier short enough to read. Where a counterparty expects a verifiable credential, the same statement can be wrapped in one.
Sources and further reading
- W3C Verifiable Credentials Data Model 2.0
- W3C Decentralized Identifiers (DIDs) v1.0
- Published implementation reports on decentralised identity deployments.
- RFC 8785 — JSON Canonicalization Scheme