Why VCALM
Both VCALM and the OpenID-based specs (OID4VCI and OID4VP) move credentials between issuers, wallets, and verifiers. The difference is who stays in control — the user, or the vendor. Here's what you get with VCALM, and where the OpenID approach differs.
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 |
The simplest way to judge for yourself: look at what a developer actually implements.
Want the formal details? Read the VCALM specification.