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.
1. Users keep their 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 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.
2. No vendor lock-in across the stack
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.
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.
3. One simple flow, not two protocols
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.
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.
4. Built for credentials, not retrofitted from login
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.
5. Works with real W3C Verifiable Credentials
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.
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.
At a glance
| What you care about | VCALM | OID4VCI / OID4VP |
|---|---|---|
| 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 |
Common questions
Is VCALM an alternative to OpenID4VP?
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.
Does OID4VCI support W3C Verifiable Credentials?
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.
When should I 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.
The simplest way to judge for yourself: look at what a developer actually implements.
Want the formal details? Read the VCALM specification.