{
"slug": "w3c-verifiable-credentials-vc-trap-enterprise-software",
"topic_id": "TOPIC-102",
"cluster": "Competitive Deconstruction",
"tier": "Tier B",
"title": "Where decentralised identity's generality becomes a cost",
"summary": "Verifiable credentials are designed to work without any shared infrastructure between issuer and verifier. That generality has a price, and most enterprise deployments do not need what it buys.",
"lede": "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.",
"date": "2024-03-10",
"category": "Comparison",
"author_id": "nadia-ferreira-strand",
"tags": [
"verifiable credentials",
"DID",
"decentralised identity",
"complexity",
"enterprise",
"comparison"
],
"image_title": "Generality Becomes A Cost",
"schema": "Article",
"key_takeaways": [
"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."
],
"body": [
{
"type": "h2",
"text": "What the stack provides"
},
{
"type": "diagram",
"kind": "compare",
"alt": "Open-ecosystem verification versus a closed deployment with one known issuer",
"caption": "The complexity is justified in the left column and unused in the right.",
"nodes": [],
"left": {
"title": "Open ecosystem",
"items": [
"Issuer unknown in advance",
"DID resolution required",
"Many methods and proof suites",
"Cross-border, no central authority"
]
},
"right": {
"title": "Your own approval records",
"items": [
"One known issuer — you",
"Keys at a well-known URL",
"One schema, one algorithm",
"Verified by you, your auditor, your regulator"
]
}
},
{
"type": "p",
"html": "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."
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "What it costs"
},
{
"type": "table",
"head": [
"Layer",
"Purpose",
"Cost in a closed deployment"
],
"rows": [
[
"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"
]
]
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "The closed case, concretely"
},
{
"type": "p",
"html": "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."
},
{
"type": "code",
"text": "# What the closed case actually needs\n issuer: known, one of them\n keys: published at a well-known URL, fetched and cached\n format: one schema, one algorithm\n proof: one signature over a canonical statement\n\n# What resolution infrastructure adds here\n a way to discover keys you already know\n a network dependency where you had none\n method negotiation for a single issuer"
},
{
"type": "p",
"html": "The complexity is not wasted in general; it is wasted here, because the problem it solves does not exist in this deployment."
},
{
"type": "h2",
"text": "The latency point, in proportion"
},
{
"type": "p",
"html": "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."
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "Choosing between them"
},
{
"type": "table",
"head": [
"Situation",
"Appropriate"
],
"rows": [
[
"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"
]
]
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "Interoperating rather than choosing sides"
},
{
"type": "p",
"html": "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."
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "What each layer costs in a closed deployment"
},
{
"type": "table",
"caption": "Complexity and where it is spent",
"head": [
"Layer",
"Purpose",
"Cost when the issuer is known"
],
"rows": [
[
"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"
]
]
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "Objections and honest limits"
},
{
"type": "p",
"html": "“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."
},
{
"type": "p",
"html": "“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."
}
],
"faq": [
{
"q": "Are verifiable credentials over-engineered?",
"a": "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."
},
{
"q": "What does an enterprise approval record actually need?",
"a": "A known issuer, keys published at a stable location, one schema, one algorithm and one signature over a canonical statement."
},
{
"q": "Is the latency argument decisive?",
"a": "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."
},
{
"q": "Can both be used?",
"a": "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."
}
],
"sources": [
{
"t": "W3C Verifiable Credentials Data Model 2.0",
"u": "https://www.w3.org/TR/vc-data-model-2.0/"
},
{
"t": "W3C Decentralized Identifiers (DIDs) v1.0",
"u": "https://www.w3.org/TR/did-core/"
},
{
"t": "Published implementation reports on decentralised identity deployments."
},
{
"t": "RFC 8785 — JSON Canonicalization Scheme",
"u": "https://www.rfc-editor.org/rfc/rfc8785"
}
],
"related": [
{
"slug": "cryptographic-receipt-primitive-rfc8785-ed25519-vs-jwt",
"title": "A session token is not an audit record",
"category": "Compliance"
},
{
"slug": "open-non-repudiation-receipt-specification-rfc-draft",
"title": "An open receipt specification",
"category": "Compliance"
},
{
"slug": "mastercard-verifiable-intent-vs-manav-deconstructing-sd-jwt",
"title": "Payment envelopes versus rendered statements",
"category": "Comparison"
}
],
"image": "https://cdn.twc.sh/images/igcache/Generality%20Becomes%20A%20Cost/1500_900/blog.jpg",
"wordcount": 858,
"url": "/blog/w3c-verifiable-credentials-vc-trap-enterprise-software.html",
"reading_time": "4 min read",
"meta_description": "Verifiable credentials are designed to work without any shared infrastructure between issuer and verifier.",
"hub": {
"slug": "topics/category-comparisons",
"title": "Category comparisons"
},
"answer": "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.",
"answer_q": "When are W3C Verifiable Credentials the wrong tool?",
"entities": [
{
"name": "W3C Verifiable Credentials",
"type": "Thing",
"url": "https://www.w3.org/TR/vc-data-model-2.0/",
"primary": true
},
{
"name": "Decentralized Identifiers",
"type": "Thing",
"url": "https://www.w3.org/TR/did-core/"
}
],
"glossary": [
{
"term": "DID",
"def": "Decentralized Identifier: an identifier that resolves to a key document through a method-specific mechanism, without a central registry."
},
{
"term": "Proof suite",
"def": "The cryptographic scheme securing a credential. Plurality is a feature in open ecosystems and implementation surface everywhere else."
},
{
"term": "Envelope",
"def": "The serialisation wrapping a signed statement. Changing it does not change what the evidence says."
}
],
"checklist": {
"title": "Choosing the right envelope",
"id": "choose",
"desc": "Four questions that settle it.",
"steps": [
{
"name": "Is the issuer known in advance?",
"text": "If yes, resolution infrastructure is solving a problem you do not have."
},
{
"name": "Must this verify in ten years?",
"text": "Then minimise moving parts and publish keys durably."
},
{
"name": "Do counterparties expect a specific format?",
"text": "Alignment can outweigh simplicity; wrap rather than rebuild."
},
{
"name": "Can a sceptical party reimplement your verifier?",
"text": "If not, the evidence depends on your tooling rather than on the format."
}
]
},
"cta": {
"title": "Where this fits in Manav",
"html": "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.",
"href": "../architecture.html",
"label": "Read the architecture"
}
}