OID4VCI
Also called OpenID4VCI, OpenID for Verifiable Credential Issuance, credential issuance protocol
OID4VCI is the protocol by which an issuer hands a verifiable credential to a holder's wallet. It is OAuth 2.0 with the payload changed: instead of returning an access token that lets you call an API, the token endpoint returns a credential you keep, present later, and can show to someone who never talks to the issuer.
Why it exists
Before it, every credential issuer invented its own hand-off. A wallet that wanted to accept credentials from ten issuers implemented ten integrations, and an issuer that wanted reach implemented one per wallet. OID4VCI collapses that into a profile of a protocol both sides already run, which is the entire reason it spread faster than the credential formats it carries.
What it does not decide
OID4VCI moves a credential; it says nothing about what the credential means, how it is signed, or whether it can be revoked. Those are the credential format, the signature suite and the status mechanism, and they are chosen independently. A correct OID4VCI implementation can still issue a credential nobody should trust.
Where Solidus uses it
Issuance for the verification flow: a completed check produces a credential the holder collects over this protocol rather than receiving as a file. The pre-authorized code flow is what runs, which suits the case where the user has just finished verifying and the issuer already knows who they are.
Where it comes from
Someone else specified this. Solidus assembles it.
Specified by the OpenID Foundation's Digital Credentials Protocols working group. It extends OAuth 2.0 so that the thing being issued is a verifiable credential rather than an access token, which is why an engineer who has implemented an OAuth client already knows most of it. Solidus implements the specification; it did not design the protocol.
How to check this
Running in production today.
Fetch https://capture-api.solidus.network/.well-known/openid-credential-issuer with no account. It returns 200 and the issuer metadata the specification requires, so the discovery half is checkable without trusting this description. The implementation is verify/apps/backend/src/modules/oid4vci/ (routes, service, types and well-known), with its grant table in migration 007_oid4vci_grants.sql.