Same-device and cross-device flows explained
Every time a wallet proves something to a website, the two have to find each other. Sometimes they are already on the same phone and the hand-over is a single tap. Sometimes the website is on a desk and the wallet is in a pocket, and the only bridge between them is a code on the screen. These are the same-device and cross-device flows, and almost every question about digital credentials in practice comes back to which of the two you are in.
Two shapes of the same exchange
What the two flows have in common is everything that matters to the business: the same question is asked, the same person approves it, and the same proof comes back. Nothing about what you are allowed to ask for, or what you can rely on afterwards, depends on which one you are in.
What differs is the route. In one the wallet is a tap away and gives the answer straight back to the page that asked. In the other the answer travels from a second device to your servers, and the page the person is looking at has to be told that it arrived.
Same-device
One phone. Website and wallet on the same screen.
- The visitor is on the site in their phone browser and asks to prove something.
- The site opens the wallet with a deep link or a redirect.
- The wallet shows who is asking and what for, and the visitor approves.
- The wallet redirects back to the site with the answer, in the same browser session that started.
Cross-device
Two devices. Website on a desktop, wallet on a phone.
- The visitor is on the site in a desktop browser and asks to prove something.
- The site shows a QR code that carries the request.
- The wallet on the phone scans it, shows who is asking, and the visitor approves.
- The wallet sends the answer to the site backend, which tells the desktop page the exchange is done.
When each one happens
You do not get to pick. A customer who opens your onboarding page on their phone during a commute is in a same-device flow. The same customer, finishing the same form at a desk the next morning, is in a cross-device one. The wallet lives on a phone, so the flow follows wherever the rest of the work is happening.
That is why both protocols in the European ecosystem describe both. Presentation, where you ask someone to prove something, names the two flows explicitly. Issuance, where you hand someone a credential, makes the same distinction for the offer that starts it: it can appear on the device the wallet is on, or arrive by any other route, down to a letter with a printed code.
A service used only inside your own organisation, on managed desktops, can reasonably launch with one flow. Anything a citizen or a customer reaches on their own terms needs both, and a service that only works one way will be reported as broken rather than as unsupported.
What each one costs the person using it
Same-device is the shorter path. There is no second screen, no camera, no moment of looking from one device to another, and the person ends up back where they started. When it fails it usually fails early and visibly: no wallet installed, or the link opens something that is not a wallet at all.
Cross-device costs a scan, but it buys something real. The person stays on the large screen where they were filling in a long form, reading a contract or comparing options, and only the proof itself moves to the phone. For anything that takes more than a minute of typing, that is the better place to be.
Its failures are quieter and worth designing for. A code that expired while someone looked for their phone, a phone with no signal, a camera that will not focus. The page showing the code should say how long it is valid, offer a new one without losing the form underneath, and never leave the person guessing whether anything happened.
Where the two genuinely differ: security
In a same-device flow the answer comes back the way the person went: a redirect, on the device the wallet runs on, into the browser session that started the exchange. Someone who copies the request off their own screen has no way to receive the result, because it is delivered to the device that did the approving.
In a cross-device flow the answer does not come back through the browser at all. It goes from the phone to your servers, out of sight of the page that showed the code. That is the gap: unless you tie the code to the session that displayed it, your service cannot tell the difference between the person in front of it and someone who put the same code in front of a victim and waited.
That attack has a name and a remedy. The code must belong to one session and one session only, and a result that arrives for any other session has to be refused. It is a few lines of thinking at design time and a known hole if it is skipped, which is why the IETF wrote a best current practice for cross-device flows rather than leaving it to each implementation.
The second risk is phishing, and it belongs to the code itself. A square of black and white tells the person nothing about who is on the other end, so a code printed on a sticker and pasted over a real one is a credible attack. The defence is that the wallet, not the code, names the organisation asking and lists exactly what it wants before anything is shared. Issuance adds one more lock: an offer can require a short code delivered on the channel that already identified the person, so an offer picked up in transit cannot be redeemed by anyone else.
What this means for you
Relying party
Plan for both from the start. The extra work is in your front end and in binding the code to a session, not in a second integration, and retrofitting the binding later is the part that goes wrong.
Issuer
Decide how your offer reaches people. On screen next to a login, in an email, or on paper, each one lands in a different flow, and the ones that leave your channel are the ones that need a separate code to redeem.
Wallet holder
Read what the wallet shows you, not what the page or the code claims. The wallet is the only place that names who is asking and what they want, and it is the last point at which you can say no.
Related terms
Frequently asked questions
Who decides which flow is used?
The situation does, not a setting. If the person is already on the device their wallet is on, the site hands over directly. If they are on a desktop and the wallet is in their pocket, the only way across is a code to scan. A service that is open to the public will meet both within its first week.
Does supporting both mean building everything twice?
No. The request you make and the answer you check are the same in both cases. What differs is how the request reaches the wallet and how the answer comes back to your page: a redirect the browser follows, or a code on screen plus a way for that page to learn the exchange finished. In practice that is one extra path in your front end, not a second integration.
Is a QR code safe to use for this?
It is safe when the exchange around it is built properly. A code on its own tells the person nothing about who is asking, so two things have to be true: the wallet must show the identity of the organisation asking before anything is shared, and your own service must refuse an answer that arrives for a session other than the one that displayed the code. Both are standard practice and both are written down in the specifications.
Is a check at a counter a cross-device flow?
No, that is a third case. Same-device and cross-device both describe an exchange over the internet. A check that happens face to face, with the two devices held next to each other, uses a proximity standard over Bluetooth or NFC instead. It looks similar to the person holding the phone, but nothing travels over your website.
Sources
This page is informational and does not constitute legal advice. For authoritative guidance consult the OpenID and IETF specifications directly.