The Digital Credentials API explained
The Digital Credentials API is the agreement that lets a website ask for a credential from your wallet directly, through the browser and the operating system of the device you are already holding. On the phone that holds your wallet, no QR code appears and you are not sent out to another app and back again. You tap once, your phone shows you who is asking, and you decide. On a laptop, the browser shows its own QR code to reach your phone.
The detour it removes
Until now a website that wanted something from a wallet had to get the request across to that wallet somehow. In practice that meant putting a QR code on the page, or opening a link that hands the visitor over to an app and hopefully brings them back. Both work, and both leak people at every step.
It is worst on a phone, where the QR code sits on the same screen as the camera meant to scan it. The Digital Credentials API closes that gap by making the request something the browser and the operating system can carry themselves, because they already know which wallets are on the device.
Same device
The visitor is on the phone that holds the wallet. This is where the Digital Credentials API removes the QR code and the app switch outright.
Across two devices
The visitor is on a laptop and the wallet is on a phone, so something still has to bridge them. The difference is that the browser can present and manage that code itself.
What it looks like in practice
From the visitor’s side it is a single tap on the page they were already on. Underneath, the browser hands the request to the operating system, the operating system finds the wallets that can answer it, and the wallet shows the request for approval before anything is shared.
1. Website
Asks the browser for a credential instead of drawing a QR code or opening an app
2. Browser and operating system
Works out which wallets on the device hold something that matches, and offers only those
3. Holder
Sees who is asking and for what, picks a wallet, and approves or refuses
4. Website again
Receives the approved answer on the same page the visitor never left
Why the browser being involved matters
A QR code is a piece of paper or a picture on a screen, and it cannot tell you who put it there. That is the whole basis of QR phishing: an attacker swaps the code, the wallet opens, and the request looks entirely normal because nothing in the flow knows where it really came from.
When the request travels through the browser, the browser is the one telling the wallet which website is asking, and it cannot be talked out of the truth. The wallet can show the real site to the holder, and the answer can be tied to that site, so a copy captured elsewhere is of no use to anyone. That is a meaningful reduction in fraud exposure, not just a smoother screen.
How it fits with OpenID4VP and the EUDI Wallet
It is easy to read this as yet another standard to choose between. It is not. OpenID4VP stays the language a relying party uses to say what it needs and to read the answer it gets back, and the Digital Credentials API is simply a better road for that conversation to travel on, most obviously when everything is happening on one device.
The same is true of the credential itself. An EUDI Wallet attestation or an mdoc arrives in exactly the format it would have arrived in over a scanned code, so the checks a verifier already runs are unchanged. What a team gains is the option to skip the detour, without rebuilding anything behind it.
Support arrives browser by browser and platform by platform rather than everywhere at once, which is why relying parties adopt it alongside the scanned route rather than instead of it. The practical approach is to use the API where the device offers it and fall back to a code where it does not, and to let the fallback fade as coverage grows.
What this means for you
Relying party
Fewer people abandon the flow, because the steps where they used to drop out are gone, and the browser tells the wallet who you really are, which takes a phishing route off the table.
Wallet holder
One tap on the page you are already on, an honest name for whoever is asking, and no way for a site to learn which wallets you carry unless you say yes.
Wallet provider
Your wallet is offered by the operating system whenever it holds something that fits, so being found no longer depends on a relying party choosing to link to you.
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
Does this mean the end of QR codes?
No, it narrows what they are for and changes who draws them. Moving a request from a laptop to a phone still needs something to bridge the two, and the API covers that case as well, with the browser presenting the code instead of every website building its own. What disappears outright is the code on a phone that already holds the wallet, where it was never anything but a workaround.
Does the website get to see which wallets I have installed?
No. The website describes what it is asking for, and the operating system does the matching on the device. The site is never told which wallets are installed or which ones held a match. If you refuse, all it learns is that nothing came back, which looks exactly the same to it as you having no matching credential in the first place.
Is this a replacement for OpenID4VP?
No, the two work together. OpenID4VP is the language the request and the answer are written in, and it does not change here. The Digital Credentials API is the delivery route on the device, taking the place of a QR code or a custom link. A relying party that already speaks OpenID4VP keeps its existing request and verification logic.
What does a relying party actually have to build?
Less than most teams expect, because the part that changes is the front end. The request your backend produces and the checks it runs on the answer stay the same. What you add is the browser call and, for as long as support is still spreading, a fallback to the QR code route for visitors whose browser or device cannot use the API yet.
Sources
This page is informational and does not constitute legal advice. The Digital Credentials API is still moving, so consult the W3C specification directly for the authoritative wording.