OpenID for Verifiable Credentials: OID4VCI and OID4VP Explained

A verifiable credential is only useful if there is an agreed way to get it into your wallet and an agreed way to show it to a service that asks. The credential format answers "what does the proof look like." The protocols answer "how does it move." OpenID for Verifiable Credentials (OpenID4VC) is the protocol family that does the moving. It splits into two specifications: OID4VCI for issuance and OID4VP for presentation.

Both are built by the OpenID Foundation on top of OAuth 2.0 and OpenID Connect, the same authorization machinery that already powers "Sign in with" buttons across the web. That choice is deliberate, and it is most of the reason these protocols are worth paying attention to.

Why build on OAuth and OpenID Connect

OAuth 2.0 is the protocol that lets one service get scoped, consented access to something on your behalf without handing over your password. OpenID Connect is the thin identity layer on top of it that lets a service learn who you are after you sign in. Between them, they are the most widely deployed authorization and identity protocols on the internet. Engineers know them, libraries implement them, and security researchers have spent over a decade attacking and hardening them.

OpenID4VC reuses that foundation instead of inventing a new one. The flows for getting a credential and presenting a credential are expressed as OAuth flows with new endpoints and new parameters. If you have ever implemented an authorization code flow, the shape will be familiar: redirects, tokens, and consent screens, repurposed to move signed credentials rather than access tokens.

The payoff is that issuers, wallets, and verifiers do not need a brand new trust and transport stack. They extend one that already exists and is already audited.

The three roles

The same issuer, holder, verifier triangle that defines W3C Verifiable Credentials maps directly onto the protocols:

• The issuer runs a credential issuer endpoint. After you authenticate, it signs a credential and hands it to your wallet. OID4VCI governs this exchange.
• The holder is you, with a wallet app. The wallet speaks both protocols: it requests credentials from issuers and presents them to verifiers.
• The verifier (the spec calls it a relying party) asks for proof and checks the signature. OID4VP governs this exchange.

The credential never has to route through a central hub. The protocols define direct conversations between wallet and issuer, and between wallet and verifier.

OID4VCI: getting a credential into your wallet

OID4VCI stands for OpenID for Verifiable Credential Issuance. It is the protocol your wallet uses to obtain a credential from an issuer.

A typical flow looks like this:

1. The issuer offers a credential. This often starts with a link or a QR code containing a credential offer: "here is what I can issue you, and here is where to start."
2. Your wallet reads the offer and begins an OAuth authorization flow against the issuer.
3. You authenticate to the issuer and consent to receiving the credential. For a KYC credential, this is the point where the identity provider has already checked your document and matched your face.
4. The wallet receives an access token, then calls the issuer's credential endpoint with that token.
5. The issuer signs the credential and returns it. The wallet stores it under your control.

Two details matter. First, the protocol supports both a flow where you start in your wallet and a flow where you start on the issuer's site and get sent to your wallet. Second, the wallet can prove it controls a key during issuance, so the credential is bound to your wallet's key from the moment it is created. That binding is what stops a stolen credential from being replayed by someone else's wallet later.

OID4VP: presenting a credential to a verifier

OID4VP stands for OpenID for Verifiable Presentations. It is the protocol a verifier uses to ask for proof and the protocol your wallet uses to answer.

A typical flow looks like this:

1. A verifier wants proof of something. It sends a presentation request describing exactly which claims it needs. "Prove you are over 18 and a verified resident."
2. Your wallet receives the request, often by scanning a QR code or following a link.
3. The wallet shows you what is being asked and which credential can satisfy it. You approve or decline.
4. If you approve, the wallet builds a verifiable presentation: the requested claims, signed with your key, proving you hold the credential and control the binding key.
5. The verifier checks the signatures, confirms the issuer is on its trusted list, and accepts or rejects.

The presentation request is precise about what it wants, which is what makes data minimization practical. Combined with SD-JWT selective disclosure, the wallet can answer "over 18" without revealing a birth date, and "verified resident" without revealing an address. The verifier asks for the minimum, and the holder releases the minimum.

Why the verifier does not call the issuer

A property worth stating plainly: in both flows, verification is a local cryptographic check. When a verifier receives a presentation, it validates the signature against the issuer's published public key. It does not phone the issuer to ask "is this person real," and it does not learn anything about your other activity.

This is the structural difference from federated login. With a classic "Sign in with" button, the identity provider is in the loop on every login and can see everywhere you go. With OpenID4VC, the issuer signs once at issuance time and is absent at presentation time. The math carries the trust, not a live connection back to a central party.

Why open protocols beat proprietary silos

It is entirely possible to build credential issuance and presentation as a closed, vendor-specific API. Several products do. The problem is the same one that produced today's fragmented identity checks: a credential issued into one vendor's walled garden is only verifiable by services that integrated that same vendor.

Open protocols break that pattern. An issuer that speaks OID4VCI can issue to any conformant wallet. A verifier that speaks OID4VP can accept presentations from any conformant wallet, regardless of who built it. The wallet becomes a neutral piece of user-controlled infrastructure rather than a lock-in point. This is the same reason email outscaled every proprietary messaging silo of its era: an open protocol lets parties who never coordinated still interoperate.

For reusable KYC this is the whole game. The value of verifying once and reusing everywhere only materializes if "everywhere" is not gated by one vendor's integration list. Open issuance and presentation protocols are what make a single credential genuinely portable across services that have never heard of each other.

A note on where things stand: OpenID4VC is being adopted in real deployments, most prominently in the EU Digital Identity Wallet program, and the specifications have matured significantly. Some details are still settling, and not every wallet supports every option yet. The direction is clear even where the last edges are not.

Where OpenKYC fits

OpenKYC is building a reusable KYC marketplace on open standards (W3C Verifiable Credentials, OpenID4VC): verify once, hold the credential in your own wallet, reuse it everywhere, and earn every time it is used. Speaking OID4VCI for issuance and OID4VP for presentation is what lets a credential we help issue be accepted by a verifier we have no relationship with, which is exactly the point. Join the waitlist at openkyc.org.