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.
At a glance
| What you care about | VCALM | OID4VCI / OID4VP |
|---|---|---|
| What you care about | With VCALM | OID4VCI / OID4VP alone |
| User picks their wallet | Yes | Often restricted by allow-lists (HAIP) |
| Swap providers without re-integrating | Yes, across the stack | Mainly at the wallet layer |
| Present and receive in one flow | One exchange loop | Two separate protocols |
| Designed around the credential holder | Yes | Inherits an OAuth/login shape |
| Carries W3C Verifiable Credentials | Natively | Excluded from the high-assurance profile |
| 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
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