Verifiable credentials as a protocol: Open Badges 3.0 is sound, the adoption graph is broken

Every few months, the credentialing community debates whether Open Badges 3.0 is ready for prime time. The format is. The adoption graph isn’t. This is a different conversation than the one most of the field is having — and the difference is where the actual work lives.

The spec is sound: stop relitigating it

Open Badges 3.0, built on the W3C Verifiable Credentials Data Model, is a healthy specification. It does what a credentialing format should do. It supports cryptographic signing of issuer identity. It links evidence — artifacts, rubric evaluations, assessment outputs — to the credential itself. It enables portability: a learner holds their credential in a wallet, presents it to a verifier, and the verifier can independently confirm issuance without a round-trip to the issuer. It supports revocation through status lists. It is machine-readable and semantically structured. The format sits cleanly in the credentialing trust stack as the issuance and verification layer — the signed claim that travels between issuer and verifier, carrying its own provenance.

I’m not going to relitigate the spec. The standards bodies did the work. The format is expressive enough. It handles the cases that matter: evidence-linked micro-credentials, stackable achievements, issuer identity via DID or centralized resolver, revocation for credentials that expire or are revoked. The cryptographic primitives are sound. The data model is coherent. If you shipped a credential today in Open Badges 3.0, the credential itself would be trustworthy at the format level. That is not the failure mode.

The failure mode is that almost nobody on the receiving end reads it.

The adoption graph is broken

A credential format only matters if someone reads it. And by “someone,” I don’t mean the learner who holds it or the issuer who minted it. I mean the receiver — the HR system, the applicant tracking system, the employer verification workflow, the licensing board, the professional registry, the admissions office. That side of the graph overwhelmingly does not parse Verifiable Credentials or Open Badges metadata. It parses brand, degree title, and institution name. Sometimes it parses a transcript PDF. The metadata — the actual verifiable claim, the linked evidence, the revocation status, the issuer’s cryptographic identity — is ignored. Not because it’s unreadable. Because the receiver has no incentive to read it and no penalty for ignoring it.

This is the last mile, and the last mile is where the spec dies. A learner presents an Open Badges 3.0 credential. The ATS extracts the human-readable title (“Data Engineering Micro-Credential, Mneurix Lattice”) and discards the JSON-LD payload. The human reviewer sees the title and recognizes “Mneurix” — or doesn’t — and makes a decision. The signature is never resolved. The revocation status is never checked. The evidence is never opened. The credential’s verifiable properties — the entire point of the format — evaporate at the receiver’s intake layer. What remains is a string of text in a field that could have been typed by hand. The format’s integrity is intact; the consumption path strips it to a brand proxy.

This is not a hypothetical. If you talk to anyone who has tried to issue verifiable credentials into the employment market, they describe the same wall. The credential is minted, signed, evidence-linked, portable — and lands in an ATS that treats it as a line item on a resume. The verification infrastructure the spec provides is never invoked. The receiver’s system doesn’t have a resolver, doesn’t have a revocation check, doesn’t have an evidence viewer. It has a text field.

Why receivers don’t read it

Receivers optimize for cheap signal. A brand proxy — “Stanford,” “Google,” “AWS Certified” — is cheap to consume. The receiver recognizes the brand, maps it to a internal rubric, and moves on. Resolving a Verifiable Credential’s signature requires the receiver to fetch a DID document or resolve a public key, check the cryptographic proof, query a revocation status list, parse the evidence URIs, render the evidence in a human-legible way, and integrate all of that into a hiring or licensing workflow that was built to process text fields. Each of those steps has a cost — engineering, maintenance, vendor integration, staff training. The brand proxy has none of those costs.

The receiver’s economics reward brand-proxy consumption and penalize the resolution of machine-readable credentials. The spec being sound doesn’t change that. You can have the most expressive, cryptographically rigorous, evidence-rich credential format in the world, and if the receiver’s cheapest path is “read the brand name and move on,” that is what the receiver does. This is not irrational. The receiver is optimizing for throughput and cost, and the brand proxy is the cheapest signal that has historically worked well enough.

This is fundamentally a two-sided market problem. As I argue in the strategy layer, credentialing is a two-sided market — and the verifier side is over-served with brand proxies. The over-service is precisely what blocks adoption of the machine-readable format. Issuers can mint perfect credentials. But if the demand side — receivers — has no reason to consume anything beyond the brand proxy, the credential’s verifiable properties are dead weight. The market clears on brand, not on evidence.

The failed fix-iteration

The standards bodies have noticed low adoption. Their response has been to improve the spec. Open Badges 2.0 became 3.0, aligning more closely with W3C Verifiable Credentials, adding expressiveness, improving the data model, expanding the alignment and evidence fields. Each iteration assumes adoption is a trailing variable that will catch up once the format is good enough. It won’t, because the bottleneck is not the spec’s expressiveness. The bottleneck is the receiver’s incentive and tooling. Polishing the spec while the receiver ignores it is the wrong loop.

Here is the gap I want to name directly: credentialing-standards coverage obsesses over the issuer-side format and assumes adoption is a receiver-side foregone conclusion. The assumption is that if the format is good enough, receivers will naturally consume it. This is wrong. Nobody treats receiver legibility as the thing that has to be built — with its own incentives, its own tooling, its own standards, its own market-making. The format had IMS Global (now 1EdTech) and W3C. The receiver has nobody. There is no standards body for “how an ATS resolves a Verifiable Credential.” There is no working group for “how an HRIS ingests evidence-linked micro-credentials into its competency framework.” The receiver side is an orphan in a field that has spent a decade perfecting the issuer side.

Every spec revision deepens the asymmetry. The issuer gets more expressive tools. The receiver gets nothing — no resolver API standard, no revocation-check protocol that plugs into existing HR workflows, no evidence-viewer component that drops into an ATS. The gap widens. The format gets better. Adoption doesn’t move. The field publishes another spec revision and wonders why.

Build the receiver

The fix is not another spec revision. The fix is receiver-side infrastructure.

First, tooling: a receiver-side resolver and verification API that makes consuming a machine-readable credential cheaper than consuming the brand proxy. This means auto-resolving the signature, auto-checking revocation, auto-extracting evidence into the ATS or HRIS workflow, and presenting all of it in a clear UI for the human verifier. The receiver’s system should ingest a Verifiable Credential and produce, with zero manual steps, a verification result, an evidence summary, and a competency mapping — cheaper and faster than parsing a resume. If resolving a Verifiable Credential is cheaper than consuming the brand proxy, the receiver switches. That’s the entire mechanic. The question is whether anyone builds the thing that makes it cheaper.

Here’s what that looks like concretely. A receiver-side resolver — a verification API that takes a VC in, does the work, and hands the ATS/HRIS/licensing system something it can already use. The resolver auto-fetches the issuer’s public key, checks the signature, queries the revocation registry, and returns a binary verification result. It extracts the evidence URIs, fetches them, and returns a structured evidence summary — what was submitted, what was assessed, who assessed it. It maps the credential’s alignment fields (if the issuer followed Open Badges 3.0 conventions) against a competency framework the receiver already uses, and returns a competency mapping the HR system can filter on directly. The receiver’s workflow sees: verified / not verified, what the credential actually asserts, what evidence backs it, and which competencies it maps to. Zero manual steps. No human opens a PDF. No human calls a registrar. No human squints at a logo and guesses whether the institution is real. The credential enters the intake layer as structured data and exits as structured data. That’s cheaper than parsing a resume — and a resume doesn’t even give you a cryptographic guarantee.

The resolver is a protocol concern. It needs a standard — a receiver-side verification API spec that any HRIS, ATS, or licensing board can implement against, and that any VC issuer can target without bespoke integration. It plugs into existing workflows: the ATS doesn’t replace its intake form; it adds one resolver call behind it. The HRIS doesn’t rebuild its competency engine; it ingests the resolver’s competency mapping as an additional signal. The receiver changes nothing visible. The resolver does the work the receiver currently can’t afford to do, and it does it in milliseconds.

But tooling alone doesn’t move a market. The receiver needs a reason to read the metadata, and right now it has none — the brand proxy is free, unchallenged, and good enough for the receiver’s purposes. Make ignoring the metadata costly. Compliance requirements: if a regulator mandates evidence-backed verification for specific credential classes — licensing, security clearance, regulated professions — the receiver can’t fall back on brand. Fraud detection: a forged brand-proxy credential is invisible. A resume that says “Stanford, 2019, B.S. Computer Science” costs nothing to fabricate and nothing to paste into an ATS. A forged VC is cryptographically detectable — the signature fails, the revocation check fails, the evidence doesn’t resolve. The receiver that consumes VCs gets fraud detection for free; the receiver that consumes brand proxies gets none. Portability and interoperability mandates: if a professional body requires that credentials be machine-verifiable across systems, the receiver has to consume the format or lose access to the credential pool. The receiver has to be built, staffed, and incentivized. The spec won’t do any of that. The receiver is the demand side. Building the receiver that consumes evidence-first credentials is the missing half of the two-sided market — and it’s the half nobody owns.

Honest about the difficulty

Honest about the difficulty: this is harder than building the spec, and I want to be precise about why. The spec had a standards body. 1EdTech, W3C — organized, funded, iterative. The receiver has no equivalent. The receiver is a diffuse market: thousands of HR systems, tens of thousands of employers, hundreds of licensing boards, each with its own procurement cycle, its own intake workflow, its own risk tolerance. There is no single receiver-side standards body because there’s no single receiver. You can’t convene them the way you convene issuers. You can’t ship a spec revision and wait. The fix is partly protocol — the resolver API standard, designed to slot into existing systems with minimal integration friction — and partly market-building. You get a wedge. A cluster of receivers in one domain — say, professional licensing, or a cohort of employers in a regulated industry — consuming evidence-first credentials through the resolver. You demonstrate the value: faster intake, lower fraud, defensible compliance. Then network effects pull the rest. Issuers see receivers consuming VCs and have a reason to issue more. More issuance makes the resolver more valuable to the next receiver. The loop tightens.

This is a slow, market-building problem. There is no shortcut via another format iteration. OB 3.1, OB 4.0, another evidence schema, another alignment taxonomy — none of it moves the receiver. The receiver doesn’t care about the spec’s expressiveness. The receiver cares about cost, speed, and risk. Give it a tool that lowers all three, and it consumes. Don’t, and it doesn’t — and the credential dies at the last mile regardless of how sound the format is.

Coda

The spec is sound. Stop polishing it. The adoption graph breaks at the receiver, and the receiver has to be built — tooling first, then incentives, then a standards body for the demand side. A credential format nobody reads is a credential format that doesn’t exist in practice, no matter how elegant the schema, no matter how robust the signature, no matter how rich the evidence links. Build the receiver, or accept that the credential dies at the last mile.