Why VCALM
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.
You keep your choice of wallet
With VCALM: a credential works with any conformant wallet. The user picks the app they trust; no one upstream decides for them.
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.
You can switch providers without re-integrating
With VCALM: interoperability is defined across the whole 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.
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.
Real protocol choice — OID4 included
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.
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.
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.
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.
Native W3C Verifiable Credentials — and the rest
With VCALM: standards-compliant W3C Verifiable Credentials travel natively, and VCALM can carry other formats and protocols too — so you're never forced to choose sides on format.
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.
At a glance
| What you care about | With VCALM | OID4VCI / OID4VP alone |
|---|---|---|
| Phases of the lifecycle covered | Issue → deliver → present → status → refresh | The delivery hand-off |
| Run OID4VCI / OID4VP | Yes — carried over VCALM | Yes (that's all it is) |
| User picks their wallet | Yes, by default | Can be restricted by allow-lists (HAIP) |
| Switch providers without re-integrating | Yes, across the stack | Mainly at the wallet layer |
| Carries W3C Verifiable Credentials | Natively (plus SD-JWT, mdoc) | Excluded from the high-assurance profile |
| Resists vendor lock-in lifecycle-wide | Yes — by design | Not its scope |
Common questions
Can VCALM use OID4VCI and OID4VP?
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.
What does VCALM cover that OID4 doesn't?
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.
Does VCALM support 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 — and how little that is.
Want the formal details? Read the VCALM specification.