Credential issuance explained: from offer to accepted credential
OpenID4VCI is the European standard for getting a credential into someone’s wallet: a diploma, a company registration, a certificate of inspection. Handing one over looks like a single moment to the holder, but several things have to line up behind it, and each of them can fail in its own way. This page walks through that, using a haulage company as the example.
Two ways an issuance starts
Most issuance starts with the issuer offering a credential, usually as a QR code or a link. Whether the holder then has to log in depends on one thing: does the issuer already know who it is dealing with. Both routes end in the same place, with the credential in the wallet.
The holder is already known
1. Issuer
Already knows who it is dealing with, and offers the credential there and then
2. Wallet
Accepts the offer, sometimes confirming a short code sent separately
3. Wallet
Collects the credential and locks it to this device
The holder has to log in first
1. Wallet
Starts from an offer, or goes to the issuer on the holder’s initiative
2. Issuer’s login
Takes the holder through logging in and agreeing to what will be issued
3. Wallet
Collects the credential and locks it to this device
The full lifecycle of a credential offer
An issuance runs through the steps below. Each one can fail on its own, and those failures are what a support desk ends up dealing with, so it is worth knowing where they sit before you design the process around them.
A worked example: a roadworthiness certificate for a haulage fleet
A vehicle inspection body issues a roadworthiness certificate into a haulage company’s business wallet after a routine inspection. The inspector has already confirmed who the fleet manager is at the inspection point, so there is no reason to make them log in again.
1. The offer
The terminal at the inspection point shows a QR code
Scanning it opens the wallet and shows which credential is being offered
2. What is on offer
The wallet reads the issuer’s published description of the credential
So the fleet manager sees what the certificate contains before agreeing to anything
3. Confirmation
The wallet confirms a short code the inspection body texted to the fleet manager
Someone who photographs the QR code over their shoulder still cannot collect the certificate
4. Locking it to the wallet
The wallet proves it holds a secret that never leaves the device
The certificate is tied to that secret, so a copy of it is worthless on another device
5. Issued and stored
The inspection body signs the certificate and the wallet stores it
From here the haulage company can show it to a client or an enforcement officer in seconds
When the credential is not ready yet
The example above assumes the inspection result is final. If a borderline result has to go to a senior inspector first, the certificate cannot be handed over on the spot. The standard covers that case rather than forcing the fleet manager to come back.
Issued on the spot
The holder walks away with the credential in their wallet, in one go.
Issued later
The issuer says it needs more time, and the wallet collects the credential once it is ready. The holder does not have to start over or come back in person.
Closing the loop
After issuance the wallet can tell the issuer how it ended. This is optional on both sides and delivery is not guaranteed, so it is useful for spotting a broken flow, but an issuer cannot read anything into a message that never arrives.
Wallet
Can tell the issuer how the issuance ended
Stored
The credential is in the wallet and ready to use
Failed
Something went wrong, for example the credential did not check out
Declined
The holder chose not to keep it
What this means for you
Issuer
One standard way to hand out credentials that every compliant wallet accepts, with no per-wallet integration and no portal for holders to log into.
Holder
You see what you are being given before you accept it, and it is tied to your device rather than to a login you could lose.
Verifier
Credentials arrive already checked and already bound to the wallet presenting them, so accepting one is a check rather than an investigation.
Technical deep dive
This page explains what the technology does and who it affects. Our developer documentation covers the implementation itself: the messages, the fields and the worked examples an integration team needs.
Read the technical documentationRelated terms
Frequently asked questions
When does the holder have to log in, and when not?
It depends on whether the issuer already knows who it is dealing with. An inspector who has just checked a vehicle in person does not need the fleet manager to log in again, so the credential is offered on the spot. An online service that has never met the holder sends them through its own login first. The offer itself says which of the two applies.
How does the wallet know what it is about to receive?
Every issuer publishes a description of what it issues, and the wallet reads that before anything else happens. That is what lets the wallet show the holder what the credential is and what it contains, so consent means something. It also means an issuer can add a new credential type without every wallet needing an update.
What stops someone from copying a credential to another device?
Before issuing, the wallet proves it holds a secret that never leaves the device, and the issuer ties the credential to it. A verifier can later ask the wallet to prove the same thing again. A copy of the credential without that secret fails the check, so copying the file achieves nothing.
What if the credential cannot be issued straight away?
Some checks take longer than a person is willing to wait: a manual review, or a query to a slow external register. The issuer can say so, and the wallet collects the credential once it is ready. The holder does not have to start again or come back in person.
Does the issuer find out whether the credential was actually kept?
It can, but only as a courtesy. The wallet may report that the credential was stored, that the holder declined it, or that something failed. Neither side is required to support this and delivery is not guaranteed, so an issuer should treat it as useful signal and never as a record of what happened.
Sources
This page is informational and does not constitute legal advice. For authoritative guidance consult the OpenID Foundation and the European Commission directly.