How Does a Credential Get to Your Wallet? DIDComm v2 vs OpenID4VC

Two rival answers to the same question, and Solidus has one of each, in two products that are not this one.

The two families

OpenID4VC, the web answer. Built on OAuth 2 and OpenID Connect. The wallet performs an authorization flow, gets a token, and calls an endpoint. Request/response, HTTPS, stateless-ish, and every backend team already has the libraries.

DIDComm v2, the messaging answer. An encrypted, transport-agnostic message envelope between two identifiers. Asynchronous by design: the recipient does not need to be online, and messages can travel over HTTP, WebSocket, Bluetooth or anything else.

They disagree about what a credential exchange fundamentally is. OpenID4VC says it is a web transaction. DIDComm says it is a conversation between two parties who each own an identifier.

Where the real difference bites

	OpenID4VC	DIDComm v2
Shape	request/response	asynchronous messages
Both parties online?	yes, effectively	no
Needs a mediator?	no	usually yes, someone holds messages for an offline wallet
Ecosystem	OAuth-shaped, huge	identity-native, smaller
European wallet framework	the specified path	not the specified path

The mediator is the part people underestimate. If a wallet is a phone that is off half the day, something has to hold its messages, and that something sees traffic patterns, timing, and who is talking to whom, even when it cannot read the contents. A mediator is a privacy-relevant party, and "decentralised messaging" that quietly depends on one deserves the same scrutiny as any other intermediary.

OpenID4VC has no mediator because it has no asynchrony. That is a simplification and a limitation, in the same breath.

What Solidus actually does, and the correction this page exists to make

Our own content brief for this page says: "Solidus implements neither DIDComm nor OID4VC today."

That is wrong, and the way it went wrong is instructive. The brief ran its search across two directories, this product's backend and the shared packages, where the answer genuinely is zero (control: a common term matches 116 files in the same paths, so the search worked). It then stated a company-wide absence from a scope-limited measurement.

Across the whole repository, both are implemented:

DIDComm v2, on the relay product, and publicly reachable now:
```
$ curl -s https://relay.solidus.network/invite
  → {"type":"https://didcomm.org/out-of-band/2.0/invitation","id":"relay-invite-…"}
```
It is a mediator: an out-of-band invitation endpoint advertising didcomm/v2, plus a message endpoint that accepts application/didcomm-encrypted+json and unwraps the envelope. A GET on that message endpoint, /didcomm, returns "Route GET:/didcomm not found", correct, because it is POST-only, and the error body proves the router is live rather than the host being dead.

Run this session, not asserted, and you can run it yourself, with no account.
OpenID4VCI, on the verification product, with issuer metadata fetchable in one command. Detail.

So the accurate statement is: this product implements neither; other Solidus products implement one each. A scope statement, not a denial, and publishing the denial would have understated our own work, which is a defect in the same family as overstating it.

The honest bounds on that

Relay is self-labelled BETA in our own status material. Reachable is not the same as production-ready.
We have not run an interoperability test against another DIDComm implementation or another OID4VCI wallet. So no compatibility is claimed, and none is implied to fail.
Neither implementation is in this product, so a credential you hold here does not travel by either path today, it moves over our own SDK and HTTP surface.

Which one should you choose?

If you are building for the European framework, the OpenID4VC family is the specified path. That is the decisive practical fact, and no architectural preference outweighs it.

If your problem is genuinely asynchronous, agents, devices, wallets that are offline for hours, long-running conversations, DIDComm is doing something OpenID4VC does not attempt, and you will need a mediator you trust.