From 54382994d728e95af6df2d9638d528c02d3deb73 Mon Sep 17 00:00:00 2001 From: Derek Scruggs Date: Mon, 8 Jun 2026 17:16:47 -0500 Subject: [PATCH] Reframe Why VCALM as complementary to OID4, not a rival. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The page positioned VCALM as an alternative to OID4VCI / OID4VP and leaned on a "user vs. vendor" / "one exchange loop" framing that was combative and not quite accurate. Lead instead with the real thesis: VCALM resists vendor lock-in across every phase of the credential lifecycle, and it can carry OID4VCI / OID4VP over its exchanges — a "yes, and" rather than an "instead of." Add a lifecycle diagram showing OID4 covering the delivery hand-off while VCALM spans issue, deliver, present, status, and refresh. Soften the comparisons to highlight VCALM's strengths without dismissing OID4, drop the "one exchange loop" claim, and apply the same corrections to the overlapping copy and FAQ schema on the what-is-vcalm page. Co-Authored-By: Claude Opus 4.8 --- src/what-is-vcalm.njk | 16 ++-- src/why-vcalm.njk | 177 ++++++++++++++++++++++++------------------ 2 files changed, 110 insertions(+), 83 deletions(-) diff --git a/src/what-is-vcalm.njk b/src/what-is-vcalm.njk index e34cebd..28ab843 100644 --- a/src/what-is-vcalm.njk +++ b/src/what-is-vcalm.njk @@ -25,7 +25,7 @@ structuredData: {"@type": "Question", "name": "Is VCALM a W3C standard?", "acceptedAnswer": {"@type": "Answer", "text": "Yes. VCALM is developed in the W3C Verifiable Credentials Working Group and published as a specification at w3.org/TR/vcalm."}}, {"@type": "Question", "name": "How is VCALM different from OID4VCI / OID4VP?", - "acceptedAnswer": {"@type": "Answer", "text": "OID4VCI (issuance) and OID4VP (presentation) are two separate OpenID-based protocols. VCALM handles both delivery and presentation in one exchange loop, keeps user choice of wallet, and works natively with W3C Verifiable Credentials."}}, + "acceptedAnswer": {"@type": "Answer", "text": "OID4VCI and OID4VP cover the delivery hand-off. VCALM is designed for the whole credential lifecycle (issuance, delivery, presentation, status, refresh), keeps user choice of wallet, and carries W3C Verifiable Credentials natively. VCALM can also carry OID4VCI / OID4VP over its exchanges, so it complements them rather than replacing them."}}, {"@type": "Question", "name": "What can you build with VCALM?", "acceptedAnswer": {"@type": "Answer", "text": "Anything that issues or verifies credentials: academic diplomas, product authenticity and digital product passports, professional licenses, and more."}}, {"@type": "Question", "name": "Is VCALM hard to implement?", @@ -88,13 +88,15 @@ structuredData: w3.org/TR/vcalm.

-

How is VCALM different from OID4VCI / OID4VP?

+

How does VCALM relate to OID4VCI / OID4VP?

- OID4VCI (issuance) and OID4VP (presentation) are two separate - OpenID-based protocols. VCALM handles both delivery and presentation in one - exchange loop, keeps user choice of wallet, and works natively with W3C - Verifiable Credentials. See Why VCALM for a full - comparison. + OID4VCI and OID4VP cover the delivery hand-off — moving a credential to a + wallet or presenting one to a verifier. VCALM is designed for the whole + credential lifecycle (issuance, delivery, presentation, status, refresh), + keeps the user's choice of wallet, and carries W3C Verifiable Credentials + natively. It can even carry OID4VCI / OID4VP over its exchanges, so it + complements them rather than replacing them. See + Why VCALM for more.

What can you build with VCALM?

diff --git a/src/why-vcalm.njk b/src/why-vcalm.njk index 626b783..6f56bd0 100644 --- a/src/why-vcalm.njk +++ b/src/why-vcalm.njk @@ -1,14 +1,14 @@ --- layout: layouts/base.njk -title: "VCALM vs OID4VCI / OID4VP — Why VCALM" -description: "VCALM vs OID4VP and OID4VCI: a clear comparison for issuing and verifying Verifiable Credentials. Wallet choice, no vendor lock-in, one simple flow, native W3C VC support." +title: "Why VCALM — vendor-lock-free credentials (works with OID4, too)" +description: "VCALM resists vendor lock-in across the whole credential lifecycle — and can carry OID4VCI / OID4VP too. Wallet choice, native W3C VCs, real protocol choice." permalink: /why-vcalm/ structuredData: "@context": "https://schema.org" "@type": "TechArticle" - headline: "VCALM vs OID4VCI / OID4VP" - about: "Comparison of VCALM (the VC API) with the OpenID4VC protocols" - description: "How VCALM compares to OID4VCI and OID4VP for issuing and verifying Verifiable Credentials: wallet choice, vendor lock-in, flow, and W3C VC support." + headline: "Why VCALM" + about: "How VCALM resists vendor lock-in across the credential lifecycle, and how it complements OID4VCI / OID4VP" + description: "VCALM resists vendor lock-in across every phase of the credential lifecycle and can carry OID4VCI / OID4VP, giving real protocol choice, wallet choice, and native W3C Verifiable Credentials." author: "@type": "Organization" name: "Digital Bazaar, Inc." @@ -18,99 +18,124 @@ structuredData: "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ - {"@type": "Question", "name": "What is the difference between VCALM and OID4VCI / OID4VP?", - "acceptedAnswer": {"@type": "Answer", "text": "OID4VCI handles issuance and OID4VP handles presentation as two separate OpenID-based protocols. VCALM handles both in one exchange loop, lets the user keep their choice of wallet, and carries W3C Verifiable Credentials natively. The OpenID high-assurance profile (HAIP) can restrict which wallets are accepted via attestation and allow-lists."}}, - {"@type": "Question", "name": "Is VCALM an alternative to OpenID4VP?", - "acceptedAnswer": {"@type": "Answer", "text": "Yes. VCALM is a W3C protocol that covers the same ground as OID4VCI and OID4VP for moving credentials between issuers, wallets, and verifiers, while keeping wallet choice with the user and avoiding vendor lock-in across the lifecycle."}}, - {"@type": "Question", "name": "Does OID4VCI support W3C Verifiable Credentials?", - "acceptedAnswer": {"@type": "Answer", "text": "The OpenID4VC high-assurance interoperability profile (HAIP) is scoped to SD-JWT and ISO mdoc credential formats and does not include W3C Verifiable Credentials. VCALM carries standards-compliant W3C Verifiable Credentials natively."}}, - {"@type": "Question", "name": "Why choose VCALM over the OpenID approach?", - "acceptedAnswer": {"@type": "Answer", "text": "Choose VCALM when you want users to keep their choice of wallet, want to swap providers without re-integrating across the stack, want issuance and presentation in one flow, and have standardized on W3C Verifiable Credentials."}} + {"@type": "Question", "name": "Can VCALM use OID4VCI and OID4VP?", + "acceptedAnswer": {"@type": "Answer", "text": "Yes. VCALM can carry OID4VCI and OID4VP over its exchanges, so you get real protocol choice. Adopting VCALM does not mean giving up OID4 — it means you are no longer locked to it. You can speak OID4 where it fits and other protocols where they fit, within one consistent model."}}, + {"@type": "Question", "name": "What does VCALM cover that OID4VCI / OID4VP does not?", + "acceptedAnswer": {"@type": "Answer", "text": "OID4VCI and OID4VP cover the delivery phase — moving a credential to a wallet or presenting one to a verifier. VCALM is designed for the whole credential lifecycle: issuance, delivery, presentation, status, and refresh. It keeps interoperability across every phase, which is where vendor lock-in is usually introduced."}}, + {"@type": "Question", "name": "How does VCALM resist vendor lock-in?", + "acceptedAnswer": {"@type": "Answer", "text": "VCALM defines interoperability across every phase of the credential lifecycle, not just the wallet hand-off. The user keeps their choice of wallet, and you can swap your software provider without re-integrating with every wallet and counterparty. It is designed to resist vendor lock-in during all phases of the digital credential lifecycle."}}, + {"@type": "Question", "name": "Does VCALM support W3C Verifiable Credentials?", + "acceptedAnswer": {"@type": "Answer", "text": "Yes, natively. VCALM carries standards-compliant W3C Verifiable Credentials. The OpenID4VC high-assurance interoperability profile (HAIP) is scoped to SD-JWT and ISO mdoc formats; VCALM carries those as well as W3C Verifiable Credentials, so you are not forced to choose a format."}} ] }

Why VCALM

- VCALM is an alternative to OID4VCI and OID4VP. All three - move credentials between issuers, wallets, and verifiers, but VCALM does it - in one exchange loop, keeps the user's choice of wallet, and carries W3C - Verifiable Credentials natively — where the OpenID specs split issuance and - presentation across two protocols and can restrict which wallets are - accepted. The difference is who stays in control: the user, or the vendor. + VCALM is designed to resist vendor lock-in across every phase of the + digital credential lifecycle — and, as far as we know, it's the only + protocol that does. It isn't a replacement you have to choose instead + of OID4VCI / OID4VP: VCALM can carry those protocols too. So it's a + "yes, and…" — yes, you can still do OID4, and you get wallet choice, + native W3C Verifiable Credentials, and freedom to switch providers on top. + The question isn't VCALM versus OID4. It's who stays in control: you, or the + vendor.

+
+

OID4 covers delivery. VCALM covers the whole lifecycle.

+

+ A credential has a life: it gets issued, delivered to a wallet, presented + to a verifier, checked for status, and eventually refreshed or replaced. + OID4VCI and OID4VP do one slice of that — the delivery hand-off. VCALM is + designed for all of it, which is exactly where lock-in tends to creep in. +

+
+   ISSUE  ──▶  DELIVER  ──▶  PRESENT  ──▶  STATUS  ──▶  REFRESH
+
+   |············ OID4VCI / OID4VP ············|
+   |  (the delivery + presentation hand-off)  |
+
+   |·························· VCALM ··························|
+   |        (one consistent model across every phase)        |
+    
+

+ Because OID4 standardizes mainly the hand-off, the rest of your stack — + issuance, status, refresh, the glue between them — can still tie you to one + vendor. VCALM defines interoperability across the whole line, and it can + run OID4 within it. You lose nothing; you gain the parts OID4 leaves open. +

+
+
-

1. Users keep their choice of wallet

+

You keep your choice of wallet

With VCALM: a credential works with any conformant wallet. - The user picks the app they trust; the issuer doesn't get to decide for - them. + The user picks the app they trust; no one upstream decides for them.

- The OpenID approach: its high-assurance profile (HAIP) - leans on wallet "attestation" and allow-lists — issuers and regulators can - restrict which wallet apps are accepted. That recreates the old - identity-provider model the technology was meant to replace: if only - approved wallets work, the user's choice is gone. + It's worth knowing that OID4's high-assurance profile (HAIP) leans on wallet + "attestation" and allow-lists, which let issuers or regulators restrict + which wallet apps are accepted. That can quietly recreate the gatekeeper + model the technology was meant to move past. VCALM keeps the choice with the + user by default — and you can still speak OID4 to the wallets that prefer it.

-

2. No vendor lock-in across the stack

+

You can switch providers without re-integrating

With VCALM: interoperability is defined across the whole - lifecycle — issuance, verification, status, delivery. You can swap your - provider (if they raise prices or cause trouble) and keep working with - every wallet and every other party. + lifecycle — issuance, presentation, status, delivery. If a provider raises + prices or causes trouble, you can swap them and keep working with every + wallet and every counterparty.

- The OpenID approach: interoperability is mainly at the - wallet layer. The rest of the issuance and verification stack can still - lock you to one vendor. + OID4 standardizes interoperability mainly at the wallet hand-off, so the + surrounding stack can still lock you in. VCALM closes that gap — without + taking OID4 away.

-

3. One simple flow, not two protocols

+

Real protocol choice — OID4 included

- With VCALM: presentation and delivery are the same simple - exchange loop. A real interaction — "prove who you are, then receive a - credential" — happens in one continuous flow. + With VCALM: you aren't forced to pick one delivery + protocol forever. VCALM can carry OID4VCI and OID4VP over its exchanges + alongside native VC-API delivery, so you can use the right protocol for each + wallet and counterparty within one consistent model.

- The OpenID approach: issuance (OID4VCI) and presentation - (OID4VP) are separate protocols. You pick one per interaction, so common - "present-then-receive" journeys become awkward and stitched together. + This is the heart of the "yes, and…": adopting VCALM doesn't mean leaving + OID4 behind. It means you're no longer locked to it.

-

4. Built for credentials, not retrofitted from login

+

Built around the credential holder

With VCALM: the model treats the holder as a full participant who controls their data and consents to each share.

- The OpenID approach: it inherits OAuth's shape, where a - verifier is treated like an app "acting on your behalf with your data." - That's a poor fit for how credentials actually work, and it shows up as - friction in the user experience. + OID4 inherits OAuth's shape, where a verifier is treated like an app acting + on your behalf with your data. That works for login, but it's a looser fit + for credentials, and the seams tend to show up as friction. VCALM starts + from the credential, not from login.

-

5. Works with real W3C Verifiable Credentials

+

Native W3C Verifiable Credentials — and the rest

With VCALM: standards-compliant W3C Verifiable Credentials - travel natively — and VCALM can even carry other protocols over its - exchanges, so you aren't forced to choose sides. + travel natively, and VCALM can carry other formats and protocols too — so + you're never forced to choose sides on format.

- The OpenID approach: its high-assurance profile is scoped - to specific credential formats (SD-JWT, ISO mdoc) and does not include W3C - Verifiable Credentials. If you've standardized on W3C VCs, that's a hard - wall. + OID4's high-assurance profile is scoped to SD-JWT and ISO mdoc and does not + include W3C Verifiable Credentials. If you've standardized on W3C VCs, + that's a wall in OID4 alone — and an open door in VCALM.

@@ -118,14 +143,15 @@ structuredData:

At a glance

- + - - - - - + + + + + +
What you care aboutVCALMOID4VCI / OID4VP
What you care aboutWith VCALMOID4VCI / OID4VP alone
User picks their walletYesOften restricted by allow-lists (HAIP)
Swap providers without re-integratingYes, across the stackMainly at the wallet layer
Present and receive in one flowOne exchange loopTwo separate protocols
Designed around the credential holderYesInherits an OAuth/login shape
Carries W3C Verifiable CredentialsNativelyExcluded from the high-assurance profile
Phases of the lifecycle coveredIssue → deliver → present → status → refreshThe delivery hand-off
Run OID4VCI / OID4VPYes — carried over VCALMYes (that's all it is)
User picks their walletYes, by defaultCan be restricted by allow-lists (HAIP)
Switch providers without re-integratingYes, across the stackMainly at the wallet layer
Carries W3C Verifiable CredentialsNatively (plus SD-JWT, mdoc)Excluded from the high-assurance profile
Resists vendor lock-in lifecycle-wideYes — by designNot its scope
@@ -133,36 +159,35 @@ structuredData:

Common questions

-

Is VCALM an alternative to OpenID4VP?

+

Can VCALM use OID4VCI and OID4VP?

- Yes. VCALM covers the same ground as OID4VCI and OID4VP — moving - credentials between issuers, wallets, and verifiers — while keeping - wallet choice with the user and avoiding vendor lock-in across the - lifecycle. + Yes. VCALM can carry OID4VCI and OID4VP over its exchanges, so adopting + VCALM doesn't mean giving up OID4 — it means you're no longer locked to + it. Speak OID4 where it fits, and other protocols where they fit, within + one consistent model.

-

Does OID4VCI support W3C Verifiable Credentials?

+

What does VCALM cover that OID4 doesn't?

- The OpenID4VC high-assurance profile (HAIP) is scoped to SD-JWT and ISO - mdoc formats and does not include W3C Verifiable Credentials. VCALM - carries standards-compliant W3C Verifiable Credentials natively. + OID4VCI and OID4VP cover the delivery hand-off. VCALM is designed for the + whole lifecycle — issuance, delivery, presentation, status, and refresh — + which is where vendor lock-in usually gets introduced.

-

When should I choose VCALM?

+

Does VCALM support W3C Verifiable Credentials?

- When you want users to keep their choice of wallet, want to swap - providers without re-integrating across the stack, want issuance and - presentation in one flow, and have standardized on W3C Verifiable - Credentials. + Yes, natively. The OID4 high-assurance profile (HAIP) is scoped to SD-JWT + and ISO mdoc; VCALM carries those and W3C Verifiable Credentials, + so you're not forced to choose a format.

-

The simplest way to judge for yourself: look at what a developer actually implements.

+

The simplest way to judge for yourself: look at what a developer actually implements — and how little that is.

- See the VCALM delivery flow - See the user experience + See the VCALM delivery flow + See the user experience