Skills Wallet Architecture
Verifiable Credentials, and What Coursera Should Actually Build

A Coursera certificate today is a PDF with a URL on it. The URL is the entire security model. Everything in this course follows from taking that sentence seriously.

What a certificate actually is right now

Consider the artifact a learner receives on completion. It is a rendered document containing a name, a course title, a date, a signature image, and a verification link back to coursera.org. It looks official. It is designed to look official. And structurally it is a claim about a claim: the PDF asserts that somewhere on a server there is a record, and invites you to go check.

That design has three properties, and all three are problems.

The cost of the status quo, measured honestly

It is tempting to describe the current state as broken. It is more accurate to say it is expensive and slow in ways that are invisible because they are distributed across parties who each absorb a small piece.

• The employer pays in verification latency. A background-check vendor contacting a registrar to confirm a degree is a multi-day operation with a per-check fee. That cost is only tolerable because it happens once per hire, at the end of the funnel, for a small subset of claims.
• The learner pays in unrecognized skill. A candidate who has completed nine specializations cannot present that as a single verifiable fact. They retype it into a resume, where it becomes indistinguishable from an assertion.
• The issuer pays in support load and in the strategic cost of being a dead end. Every verification request that lands as a support ticket is an operational expense on a credential you already gave away for free.

The critical asymmetry: verification cost scales with the number of claims, but the current design assumes verification is rare. The moment skills-based hiring makes verification routine — per skill, not per degree — the model collapses under its own arithmetic. That moment has arrived.

The skills-based hiring shift, with real numbers

Coursera runs its own primary research here, which is convenient because it means the strongest available data on this question is data you can cite in your own planning documents without buying a report.

Note carefully what the 94% figure does and does not say. It says employers report a willingness to pay a salary premium for micro-credential holders. It does not say they pay more for cryptographically verified credentials specifically — that study does not exist yet. The bridge between those two statements is an assumption, and it is the central commercial assumption of this entire course. State it as an assumption in any business case, because an executive who catches you conflating the two will discount everything else you said.

Market size: a range, not a number

The commonly quoted figure for this space is $1.13B growing at 21.7% CAGR. Treat it as one data point among many rather than a fact, because published estimates diverge wildly depending on what the analyst decided to count.

The scale of the credential landscape

Credential Engine's Counting Credentials 2025 report (December 2025) is the best census available:

Up from 1.08 million credentials in 2022. Certificates account for 486,352 and degrees for 264,099 — meaning badges alone now outnumber degrees roughly four to one.

Sit with that for a moment, because it reframes the problem. The scarce resource is no longer credentials. It is discrimination between them. When a hiring manager sees 1.85 million possible credentials, the signal value of any individual one approaches zero unless something distinguishes a rigorously assessed credential from a completion certificate. That "something" is the real product.

Six specifications, each solving exactly one problem, stacked so that a change at one layer does not force a change at the others. If you learn only one thing from this module, learn which layer owns which decision.

The stack, bottom to top

W3C Verifiable Credentials 2.0 — the container

Became a W3C Recommendation on 15 May 2025, alongside six sibling specifications covering JOSE/COSE securing, Data Integrity cryptosuites, Controlled Identifiers, and Bitstring Status Lists. This is a finished, stable, royalty-free web standard, not an emerging technology.

The data model is deliberately thin. A credential is:

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "id": "urn:uuid:3f9d2a1c-...",
  "type": ["VerifiableCredential"],
  "issuer": "did:web:coursera.org",
  "validFrom": "2026-08-05T14:22:00Z",
  "credentialSubject": {
    "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
  },
  "credentialStatus": { ... },
  "proof": { ... }
}

Five things worth noting, because each is a trap for people carrying v1.1 habits:

• validFrom / validUntil, not issuanceDate / expirationDate. The v1.1 names are gone in 2.0. Mixing them silently produces credentials that fail strict validation.
• issuer may be a string or an object. Use the object form when you want to carry a display name and URL, which you do for anything a human will see.
• credentialSubject.id is optional. A credential with no subject identifier is a bearer credential — anyone holding it can present it. Sometimes correct; usually not what you want for a learner achievement.
• proof is not the only way to secure a credential. The VC-JOSE-COSE spec lets you wrap the credential in a JWT instead, with no proof member at all. Two legitimate securing mechanisms, and verifiers must handle whichever you chose.
• The @context is load-bearing. JSON-LD processing means unknown terms are an error, not something to ignore. Every field you add needs a context entry.

Open Badges 3.0 — the achievement semantics

1EdTech rebuilt Open Badges on top of W3C VCs for version 3.0, and developed CLR 2.0 alongside it so the two share a data model. The practical consequence: an Open Badges 3.0 assertion is a Verifiable Credential. There is no conversion step. You add a context and a type, and the achievement-specific vocabulary becomes available.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
  ],
  "type": ["VerifiableCredential", "OpenBadgeCredential"],
  "issuer": {
    "id": "did:web:coursera.org",
    "type": ["Profile"],
    "name": "Coursera",
    "url": "https://www.coursera.org"
  },
  "validFrom": "2026-08-05T14:22:00Z",
  "credentialSubject": {
    "type": ["AchievementSubject"],
    "id": "did:key:z6MkhaXgBZ...",
    "achievement": {
      "id": "https://coursera.org/achievements/gen-ai-for-everyone",
      "type": ["Achievement"],
      "achievementType": "Certificate",
      "name": "Generative AI for Everyone",
      "description": "...",
      "criteria": { "narrative": "Completed all graded assessments with 80% or higher." },
      "alignment": [ ... ]
    }
  }
}

The two fields that carry the strategic weight are criteria and alignment, and both are routinely left empty by lazy issuers.

• criteria is what a human or agent reads to understand what the learner had to do. "Watched the videos" and "passed a proctored exam at 80%" are the same badge shape with radically different meaning. Fill this in.
• alignment points the achievement at an external skill framework — O*NET, ESCO, a competency framework, or Credential Engine's CTDL. This is what makes credentials comparable across issuers, which is what makes skills-based search possible at all.

CLR 2.0 — the bundle

A Comprehensive Learner Record allows many Open Badge achievement credentials to be bundled together with defined associations between them — another onion layer wrapping the inner set of credentials, and itself signed.

Two things this buys you that individual badges cannot:

1. Relationships. "This specialization certificate is composed of these five course certificates" is expressible as structure rather than convention. A verifier can traverse it.
2. Multi-source aggregation. A CLR can bundle credentials from different issuers into one presentable record — which is what a transcript actually is, and what a resume is pretending to be.

The subtlety worth internalizing: bundling does not re-attest. A CLR containing a third-party credential does not mean the CLR signer vouches for that credential's content. It means "I assembled these." Verifiers must check each inner credential's own proof independently. Getting this wrong is the most common CLR implementation bug — and it is a security bug, not a correctness one.

DIDs — identifiers without a registrar

A DID is a URI that resolves to a DID document containing public keys and service endpoints. The critical property: resolution requires no central authority to have issued the identifier.

How the layers actually compose

What is genuinely not settled

Issuer, Holder, Verifier. Three roles, and one property that makes the whole thing worth building: the verifier never has to talk to the issuer.

The three roles — and the fourth corner everyone forgets

What actually happens on the wire

Holder binding: proving you are the subject

The mechanism that makes a credential non-transferable is that credentialSubject.id contains the learner's DID, and presenting it requires signing with the corresponding private key. Possession of the document is not enough; you need the key.

This has a consequence people find surprising: a credential is only as non-transferable as the learner's willingness to hand over their key. Nothing stops a learner from giving someone their phone and PIN. Cryptography prevents theft, not collusion. Anyone claiming VCs eliminate credential fraud is overselling — they eliminate forgery and tampering, which is a large and worthwhile subset.

Selective disclosure — three mechanisms, honestly ranked

"Prove you have this skill without revealing your grade" is the canonical demo. Here is what actually delivers it, in ascending order of sophistication and descending order of readiness.

The unlinkability question, and why it may matter less than it seems

SD-JWT hides fields but not identity across presentations: the issuer's signature is a constant, so two verifiers who compare notes can tell they saw the same credential. BBS+ fixes this by deriving a fresh proof each time.

Whether you should care depends entirely on the credential. For an employment credential the learner is deliberately presenting under their real name to a named employer, correlation is largely moot — they already told you who they are. For an anonymous skills marketplace, or a credential asserting something sensitive (a disability accommodation, a recovery program completion), unlinkability is the whole ballgame.

Practical guidance: segment by sensitivity. Ordinary course completions do not need BBS+. If Coursera ever issues credentials touching protected categories, that class needs a different securing mechanism from day one — and as Module 2 noted, that decision is close to irreversible once issued at scale.

DIDComm — the encrypted channel, and its actual status

DIDComm v2 (Decentralized Identity Foundation) defines encrypted, authenticated, transport-agnostic messaging between DIDs. Messages are encrypted to the recipient's DID document keys and can travel over HTTPS, Bluetooth, or a mediator — enabling long-lived agent-to-agent relationships without a shared server.

A wallet is four hard problems in a trench coat: key custody, storage, protocol handling, and recovery. Three of them are solved. The fourth is why wallets are still bad.

Component architecture

Key management: the non-negotiables

• Generate on device, never transmit. A private key that touched a server is a private key the server's operator could have kept. If Coursera generates learner keys, Coursera can impersonate learners — and the entire self-sovereignty claim is theater.
• Hardware-backed and non-extractable. Use the platform keystore so signing happens inside the secure element. Malware on a rooted device can request signatures; it cannot exfiltrate the key and sign forever elsewhere.
• Bind unlock to biometrics or device passcode. Signing should require a user-presence gesture, not merely an unlocked app.
• Consider per-verifier keys. One static did:key presented to every employer is a persistent cross-verifier identifier — effectively a cookie that cannot be cleared. Pairwise DIDs fix it at real cost in complexity and credential reuse, since a credential is bound to one subject DID.

Storage: on-device versus cloud-backed

Import, export, and the multi-issuer reality

A wallet that only holds Coursera credentials is a Coursera feature, not a wallet. The import paths that must work:

1. OID4VCI credential offer — the standard path. Issuer generates an offer (deep link or QR), wallet redeems it for the credential. Works with any conforming issuer.
2. File import — a .json or .jwt credential dropped in from email or downloads. Unglamorous, and how a great deal of real-world movement happens.
3. Legacy Open Badges 2.0 — hosted or baked-in-PNG badges. Millions exist. A wallet that cannot ingest them starts empty, and an empty wallet gets deleted.

Export must be equally serious: standards-compliant credential files, an encrypted full-wallet archive, and a plain human-readable summary. If export is worse than import, you have built a roach motel and the ecosystem will notice.

Reference implementations worth studying

Revocation from the wallet's side

Wallets do not enforce revocation — verifiers do. But a good wallet surfaces it: periodically re-check status lists for held credentials and tell the learner when something has been revoked or expired, rather than letting them discover it in an interview.

This creates a genuine privacy tension. Background status polling means the wallet phones the issuer's CDN on a schedule, producing a traffic pattern tied to a device. Mitigations: batch checks across all credentials, randomize timing, route through the same CDN as everything else, and let the learner turn it off. Worth doing, worth documenting, and worth not pretending is free.

This is the module that matters most, because issuance is the part Coursera is uniquely positioned to do well and the part nobody else can do on its behalf.

The issuance pipeline

Signing infrastructure and the rotation problem

Coursera publishes did:web:coursera.org, resolved at https://coursera.org/.well-known/did.json:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/multikey/v1"
  ],
  "id": "did:web:coursera.org",
  "verificationMethod": [
    {
      "id": "did:web:coursera.org#key-2026-01",
      "type": "Multikey",
      "controller": "did:web:coursera.org",
      "publicKeyMultibase": "z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
    },
    {
      "id": "did:web:coursera.org#key-2025-01",
      "type": "Multikey",
      "controller": "did:web:coursera.org",
      "publicKeyMultibase": "z6MkjchhfUsD6mmvni8mCdXHw216Xrm9bQe2mBH1P5RDjVJG"
    }
  ],
  "assertionMethod": [
    "did:web:coursera.org#key-2026-01",
    "did:web:coursera.org#key-2025-01"
  ]
}

Practical setup: private keys in a KMS or HSM (AWS KMS with Ed25519, or CloudHSM for stricter custody), one active signing key with a documented rotation cadence, and dual control on key operations. The signing service holds a key reference, never key material.

Schema design: what goes in a Coursera credential

This is where the strategy becomes a data structure. The default is a badge with a name and a date. The differentiated version carries provenance a verifier can reason about.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
  ],
  "id": "urn:uuid:9f2a4c81-6b3e-4f77-9c21-8ad5e0e1b774",
  "type": ["VerifiableCredential", "OpenBadgeCredential"],
  "issuer": {
    "id": "did:web:coursera.org",
    "type": ["Profile"],
    "name": "Coursera",
    "url": "https://www.coursera.org"
  },
  "validFrom": "2026-08-05T14:22:00Z",
  "credentialSubject": {
    "type": ["AchievementSubject"],
    "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
    "achievement": {
      "id": "https://coursera.org/achievements/deep-learning-specialization",
      "type": ["Achievement"],
      "achievementType": "Certificate",
      "name": "Deep Learning Specialization",
      "description": "Five-course specialization covering neural networks, ...",
      "criteria": {
        "narrative": "Passed all 5 courses with a weighted average of 80% or
                      higher across 23 graded programming assignments and
                      12 quizzes. Identity verified at enrollment."
      },
      "alignment": [
        {
          "type": ["Alignment"],
          "targetName": "Deep Learning",
          "targetFramework": "Coursera Skills Taxonomy",
          "targetUrl": "https://coursera.org/skills/deep-learning"
        },
        {
          "type": ["Alignment"],
          "targetName": "Machine Learning",
          "targetFramework": "O*NET",
          "targetCode": "15-2051.01",
          "targetUrl": "https://www.onetonline.org/link/summary/15-2051.01"
        }
      ]
    },
    "result": [
      { "type": ["Result"], "achievedLevel": "Passed", "resultDescription": "..." }
    ]
  },
  "credentialStatus": {
    "id": "https://credentials.coursera.org/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://credentials.coursera.org/status/3"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2026-08-05T14:22:01Z",
    "verificationMethod": "did:web:coursera.org#key-2026-01",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DvkA9L2mHq..."
  }
}

The assessment integrity tier — the differentiating design decision

Every credential should carry a machine-readable statement of how rigorously it was assessed. Not buried in prose — as a field a verifier can filter on.

Batch issuance at Coursera scale

Suppose the retroactive backfill is on the order of tens of millions of credentials. Where does that actually hurt?

Retroactive issuance for existing completions

Millions of learners hold completions predating any of this. Backfilling is high-value — it is what makes a wallet non-empty on day one — and has three sharp edges:

1. Date semantics. validFrom is when the credential became valid; the achievement date belongs in awardedDate on the subject. A 2019 completion issued in 2026 has a 2026 validFrom and a 2019 awardedDate. Conflating them produces credentials that look backdated, which reads as fraud.
2. No subject DID. Historical learners have no wallet and no key. Two options: issue unbound credentials held in a custodial account and bind on first wallet claim, or defer issuance until claim. Prefer deferred issuance — it avoids minting tens of millions of credentials nobody ever claims, and avoids a bearer-credential population you would rather not have.
3. Retroactive integrity. Data quality on old completions is worse: missing assessment metadata, deprecated courses, changed criteria. Either backfill at a lower, honestly labeled tier, or exclude records you cannot substantiate. Do not reconstruct criteria you do not have — a signed guess is still a signed statement.

Coursera for Campus and Coursera for Business

Enterprise and campus change the issuer question, because the institution wants its name on the credential and often has accreditation standing that Coursera does not.

The sub-issuer pattern is underrated. did:web supports path-based identifiers, so did:web:coursera.org:issuers:asu resolves to https://coursera.org/issuers/asu/did.json — a distinct identity with its own keys, hosted by Coursera, requiring zero partner infrastructure. It gives partners the branding and separation they want while keeping key custody in one operationally mature place.

Issuance without verification is a science project. This module is about the side of the market that decides whether any of the previous five modules produced value.

What "instant verification" actually means

The phrase gets used loosely. Precisely, a verifier performs six checks, and only one of them requires a network call that is not aggressively cacheable:

In steady state, verification is two cached fetches and some elliptic-curve math. Sub-millisecond warm. That is the number that changes employer behavior: verification stops being a procurement decision and becomes a line in a function.

Verification API design

Most verifiers will not implement checks 1–5 themselves in year one. They will call something. Designing that endpoint well is how Coursera stays in the loop without becoming a bottleneck.

{
  "verifiablePresentation": { ... },
  "options": {
    "checkStatus": true,
    "challenge": "b3f1e7a2-...",
    "domain": "careers.acme-corp.com"
  }
}

{
  "verified": true,
  "checks": {
    "presentationSignature": "valid",
    "holderBinding": "valid",
    "credentialSignature": "valid",
    "issuerResolved": "did:web:coursera.org",
    "revocationStatus": "active",
    "validityWindow": "in_range",
    "schemaConformance": "valid"
  },
  "credentials": [
    {
      "achievement": "Deep Learning Specialization",
      "awardedDate": "2026-06-14",
      "assessmentTier": "T3_AUTO_GRADED",
      "assessmentDetail": {
        "gradedAssignments": 23,
        "passThreshold": 0.80,
        "identityVerified": true
      },
      "skills": [
        { "name": "Deep Learning", "framework": "Coursera Skills Taxonomy" },
        { "name": "Machine Learning", "framework": "O*NET", "code": "15-2051.01" }
      ],
      "effortHours": 128,
      "partner": "DeepLearning.AI"
    }
  ],
  "warnings": []
}

Skills-based candidate search

Once credentials carry alignment entries pointing at shared frameworks, a fundamentally different query becomes possible. Instead of "candidates who list PyTorch on a resume," a verifier can ask for candidates holding verified credentials aligned to a skill, above an assessment tier, within a recency window.

SELECT candidates WHERE
  verified_credential.alignment INCLUDES 'onet:15-2051.01'
  AND verified_credential.assessmentTier >= 'T3'
  AND verified_credential.awardedDate > '2024-01-01'
  AND verified_credential.issuer IN trusted_issuer_registry

Three preconditions, all of which are issuer-side decisions made in Module 5: alignments must be populated, the tier must be machine-readable, and issuer trust must be resolvable. Miss any one and the query degrades to string matching — which is what resumes already are.

Trust scoring: beyond the verified checkmark

A binary "verified" badge is a weak product. It answers "is this real?" while the employer is asking "is this good?"

ATS integration — the unglamorous reality

Applicant tracking systems are where credentials must land to matter, and the honest status is: they do not speak Verifiable Credentials. Workday, Greenhouse, iCIMS, Lever and the rest have well-developed APIs for candidates, attachments, and custom fields, and essentially no native VC support.

Two different things are called a "wallet" in this course. One holds credentials, the other holds money. The interesting question is what happens where they meet — and the answer is more constrained than it first looks.

Two wallets, one word

They intersect at exactly one point: verification is an API call, and API calls can be priced. Everything in this module follows from that sentence — including its limits.

The x402 flow applied to verification

A verification Worker with x402

const PRICE_USDC_BASE_UNITS = "50000"; // $0.05 — USDC has 6 decimals

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const body = await request.json();

    // Tier 1: basic verification is ALWAYS free. This is strategic,
    // not generous — see the note below on why gating it is fatal.
    if (url.pathname === "/v1/verify") {
      return Response.json(await verifyPresentation(body, env));
    }

    // Tier 2: enriched verification is metered via x402.
    if (url.pathname === "/v1/verify/enriched") {
      const payment = request.headers.get("PAYMENT-SIGNATURE");

      if (!payment) {
        return new Response(null, {
          status: 402,
          headers: {
            "PAYMENT-REQUIRED": btoa(JSON.stringify({
              x402Version: 2,
              accepts: [{
                scheme: "exact",
                network: "base",
                asset: env.USDC_CONTRACT,
                amount: PRICE_USDC_BASE_UNITS,
                payTo: env.COURSERA_WALLET,
                resource: url.toString(),
                description: "Enriched credential verification",
                maxTimeoutSeconds: 60
              }]
            }))
          }
        });
      }

      // Facilitator does verify + settle. We never touch a chain.
      const settlement = await settleViaFacilitator(payment, env);
      if (!settlement.ok) return new Response("Payment failed", { status: 402 });

      const result = await verifyPresentation(body, env);
      const enriched = await enrich(result, env); // skills graph, percentile, provenance

      return Response.json(enriched, {
        headers: { "PAYMENT-RESPONSE": btoa(JSON.stringify(settlement.receipt)) }
      });
    }

    return new Response("Not found", { status: 404 });
  }
};

Note what the Worker does not do: no node, no gas management, no private key, no invoicing, no metering service. The facilitator abstraction is what makes this adoptable by an ordinary backend team, and Cloudflare plays that role at the edge in its own stack.

The revenue model, with the skepticism it deserves

The seductive arithmetic: a million verifications a day at five cents is $50,000 a day, or roughly $18M a year. Before anyone puts that in a plan, interrogate the denominator.

Why Workers specifically

• Verification is embarrassingly cacheable. DID documents and status lists are static artifacts fetched by every verifier — exactly what a CDN edge is for. Serving them from Workers with long cache TTLs makes the fetch effectively free and hides verifier IPs behind the edge, which is also the privacy mitigation from Module 3.
• Verification is stateless and CPU-light. Signature checks and a bitstring lookup. No database in the hot path.
• Global latency matters for a learner population that is majority outside the US.
• x402 support is native at the edge as of Cloudflare's July 2026 Monetization Gateway, so pricing becomes configuration rather than code.

A map of who is building what, which bodies actually confer legitimacy, and where Coursera should show up versus merely watch.

Standards bodies and consortia

Velocity Network Foundation — the Internet of Careers

A non-profit membership organization operating a public permissioned blockchain for exchanging verifiable career credentials. Its pitch is HR-industry interoperability: members span HCM vendors, gig platforms, background and certification processors, education institutions, training vendors, and employers — collectively holding career data on more than a billion individuals.

Platforms and issuers

Credential Engine and the discovery layer

Credential Engine maintains the Credential Registry and the Credential Transparency Description Language (CTDL). Its Counting Credentials 2025 report (December 2025) found 1,850,034 unique US credentials from 134,000+ providers, against $2.34 trillion invested annually in US education and workforce development.

The distinction that matters architecturally: Credential Engine describes credential types; Verifiable Credentials assert instances. The registry says "this certificate exists, here is what it requires, here are the skills it maps to." A VC says "this person earned it." They are complementary, and the pairing is powerful — a verifier resolving an achievement URI into a registry description gets independent third-party context on what the credential means, from someone other than the issuer.

Publishing Coursera's credential catalog into the Credential Registry with CTDL descriptions is comparatively cheap and makes credentials discoverable to state talent marketplaces and workforce systems that query the registry directly — including the ones being funded right now.

Public-sector programs shaping demand

The incumbent in skills verification is not another course platform. It is a social network that verifies nothing and wins anyway.

LinkedIn — the incumbent to actually worry about

LinkedIn holds the world's largest repository of skill claims, a skills graph mapping people to skills to jobs, and — decisively — it is where the hiring workflow already happens. Recruiters live there. Candidates maintain profiles there. Coursera already integrates with it: on completing a Google Career Certificate, learners get a link to import the credential badge into LinkedIn's Licenses & Certifications section.

Google — the partner who is also a competitor

Google occupies an unusual position: Google Career Certificates are delivered on Coursera, making Google simultaneously one of the largest content partners and a credential brand with its own distribution ambitions.

• Google Career Certificates — the 2026 catalog spans Advanced Data Analytics, Business Intelligence, IT Automation with Python, alongside foundational Data Analytics, Project Management, and IT Support. Non-expiring, and delivered through Coursera.
• Google Cloud Credential Wallet — launched for Google Cloud credential holders, powered by Credly, with Labor Market Insights surfacing job opportunities, titles, employers, and salary data against verified skills.
• Google Wallet — increasingly a container for identity documents, and the obvious eventual home for credentials on Android.

edX / 2U and the rest of the online-education field

edX's verified certificates use ID verification at enrollment, which is a genuine integrity signal, but the credential artifact remains a hosted page rather than a portable Verifiable Credential. 2U's financial difficulties have limited investment in forward-looking credential infrastructure.

The broader field — Udacity, Udemy, Pluralsight, LinkedIn Learning — is largely in the same position: certificates as marketing artifacts rather than verifiable claims. This is a genuine opening. There is no online-learning platform at Coursera's scale with a serious verifiable-credentials program, which means first-mover advantage in this category is real and currently unclaimed.

Canvas Credentials and the LMS flank

Instructure's Canvas Credentials (formerly Badgr) issues Open Badges 3.0 from inside the dominant higher-education LMS. That is a structurally strong position: credentials issued where the coursework already lives, with no integration required by the institution.

For Coursera this is the flank to watch. If universities issue verifiable credentials natively from Canvas for their own coursework, the Coursera-delivered credential becomes one input among many rather than the record itself — and the aggregation layer (CLR) moves to the LMS. Two responses, and they are not exclusive: make Coursera credentials trivially ingestible into institutional records, and compete on the assessment provenance an LMS badge cannot carry.

Where Coursera actually differentiates

Five phases over eighteen months, with the phase-two departure from conventional wisdom flagged loudly, and explicit criteria for killing the program.

Cumulative investment shape

Organizational changes

The parts that decide whether an implementation works: securing mechanisms, DID methods, proof formats, status lists, and the lifecycle fields everyone forgets until a credential expires in production.

Two securing mechanisms, one data model

A VC 2.0 credential can be secured two ways, and a verifier must handle whichever the issuer chose. This is the single most consequential implementation decision in the stack.

The JWT form, concretely

// Header
{
  "alg": "EdDSA",
  "typ": "vc+jwt",
  "kid": "did:web:coursera.org#key-2026-01"
}

// Payload — the credential lives under "vc"
{
  "iss": "did:web:coursera.org",
  "sub": "did:key:z6MkhaXgBZ...",
  "nbf": 1785942120,
  "jti": "urn:uuid:9f2a4c81-...",
  "vc": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
    ],
    "type": ["VerifiableCredential", "OpenBadgeCredential"],
    "credentialSubject": { ... }
  }
}

Note there is no proof member. The JWS signature is the proof, and kid points at the verification method in the issuer's DID document. A verifier that only knows how to look for proof will reject this as unsigned — a common and confusing interop failure.

Proof formats and cryptosuites

Ed25519 is the right default: 64-byte signatures, fast verification, no curve-parameter footguns, and support in every relevant library. Move off it only for a specific reason — a FIPS requirement pushes you to P-256, and a genuine unlinkability requirement pushes you to BBS+ with the understanding that tooling is thinner.

How SD-JWT actually achieves selective disclosure

Elegant, cheap, and it explains the linkability limitation precisely: the JWT signature is identical across every presentation, so two verifiers comparing notes can tell they saw the same credential even if they saw different fields.

Bitstring Status List mechanics

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "id": "https://credentials.coursera.org/status/3",
  "type": ["VerifiableCredential", "BitstringStatusListCredential"],
  "issuer": "did:web:coursera.org",
  "validFrom": "2026-08-05T00:00:00Z",
  "credentialSubject": {
    "id": "https://credentials.coursera.org/status/3#list",
    "type": "BitstringStatusList",
    "statusPurpose": "revocation",
    "encodedList": "uH4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
  },
  "proof": { ... }
}

Mechanics and sizing:

• The list is a GZIP-compressed, base64url-encoded bitstring. Minimum length is 131,072 entries (16 KB raw) — and because revocations are rare, the compressed payload is typically a couple of kilobytes.
• Each credential carries its index in credentialStatus.statusListIndex. The verifier decompresses and reads one bit.
• statusPurpose distinguishes revocation from suspension. Revocation is permanent; suspension is reversible. Different lists, different semantics — a suspended credential can come back.
• The status list is itself signed, so a verifier can confirm the revocation data genuinely came from the issuer rather than an attacker who intercepted the fetch.

Credential refresh and expiration

A verifier, end to end

async function verifyPresentation(vp: object, opts: VerifyOptions) {
  const checks: Record<string, string> = {};
  const warnings: string[] = [];

  // 1. Presentation signature + replay protection.  DO NOT SKIP.
  const holderDid = getHolder(vp);
  const holderDoc = await resolveDid(holderDid);
  if (!(await verifyProof(vp, holderDoc))) throw new Error("bad presentation signature");
  if (getChallenge(vp) !== opts.challenge) throw new Error("nonce mismatch");
  if (getDomain(vp) !== opts.domain)       throw new Error("domain mismatch");
  checks.presentationSignature = "valid";

  for (const vc of getCredentials(vp)) {
    // 2. Holder binding — the credential must be about the presenter.
    if (vc.credentialSubject.id !== holderDid) throw new Error("holder binding failed");

    // 3. Resolve issuer and verify the credential signature.
    const issuerDid = typeof vc.issuer === "string" ? vc.issuer : vc.issuer.id;
    const issuerDoc = await resolveDid(issuerDid);          // cached for hours
    const vm = findVerificationMethod(issuerDoc, proofKeyId(vc));
    if (!vm) throw new Error("unknown verification method");
    if (!(await verifyProof(vc, vm))) throw new Error("bad credential signature");

    // A retired key is a WARNING, not a failure — historical credentials
    // stay valid, which is exactly why retired keys are never deleted.
    if (isRetired(vm)) warnings.push(`signed with retired key ${vm.id}`);

    // 4. Revocation — one fetch covers ~131k credentials.
    if (vc.credentialStatus && await isRevoked(vc.credentialStatus)) {
      throw new Error("credential revoked");
    }

    // 5. Validity window and schema.
    assertValidityWindow(vc);
    assertSchema(vc);
  }

  // 6. Issuer trust — POLICY, not cryptography. Yours to define.
  //    Everything above is mechanical; this line is the actual decision.
  return { verified: true, checks, warnings, trustDecision: opts.trustPolicy(vp) };
}

Learner-held credentials improve the privacy posture on almost every axis — and create two genuinely new problems that the architecture makes harder, not easier.

GDPR: better on most axes, genuinely harder on one

The erasure paradox, resolved

An issued credential is a signed document in the learner's possession, possibly copied to verifiers. Coursera cannot reach into a wallet and delete it. So what does erasure mean?

FERPA: verifiable credentials are close to the ideal case

FERPA governs education records at US institutions receiving federal funding. Coursera's own position varies by product line — direct-to-consumer courses are generally not FERPA-covered, while degree programs delivered with university partners typically are, with Coursera acting under the school-official exception. That distinction should be settled per product line before Phase 1, because it changes who may authorize disclosure.

Where the architecture helps, the help is structural rather than incidental:

• Disclosure becomes learner-initiated by construction. FERPA's core mechanism is consent for disclosure of education records. A VC presentation is a consent event: the learner chose to present, to a named verifier, at a specific time. That maps to FERPA's model more cleanly than any consent checkbox.
• Selective disclosure is data minimisation for records. Sharing a credential rather than a transcript discloses less by default.
• The audit trail lives in the right place. The wallet can log every presentation for the learner, giving them a record of who they shared with — which is closer to FERPA's spirit than an institutional log the learner cannot see.

Correlation: the new risk the architecture creates

A learner presenting the same did:key to every verifier has handed out a persistent, unique, cross-context identifier — effectively a cookie that cannot be cleared and that they cannot see.

Cross-border portability

• The credential itself crosses borders trivially — it is a signed document verified against a public key, with no data transfer to a third country in the GDPR sense when a learner presents their own credential to a foreign verifier.
• EU recognition runs through EDC/ELM. Mapping Coursera achievements into the European Learning Model is what makes them describable in EU frameworks, and the December 2026 EUDI mandate makes this a dated requirement rather than an aspiration.
• The issuer-side data — the completion record, the issuance log — remains subject to ordinary transfer rules and is unaffected by any of this.
• Trust does not cross borders automatically. A European verifier may not recognize did:web:coursera.org as an accredited issuer, which is the trust-registry gap from Module 2 wearing a jurisdictional hat. National accreditation registries are the emerging answer, and they are not interoperable yet.

Accessibility and the equity question

The revocation policy question

Technical revocation is easy. The policy is not, and it must be written before the first credential is signed:

• Academic integrity violation discovered after issuance — revoke. Clear case.
• Issuance error (wrong course, wrong learner, wrong tier) — revoke and reissue correctly.
• Course later found to be substandard — do not revoke. The learner did the work in good faith. Deprecate the achievement definition instead so no new credentials are issued.
• Partner relationship ends — do not revoke. The achievement happened. Nothing about it became false.
• Learner requests deletion — revoke plus erase Coursera's copy, subject to the status-list retention question above.
• Legal order — revoke, and publish transparency reporting on the aggregate.