Same-device vs cross-device flow

In a same-device flow the wallet and the website or app are on the same phone. The site hands the visitor over with a deep link or a redirect, the wallet opens, the person approves what is being asked, and the wallet sends them back to the site the way they came. OpenID4VP returns the presentation in the fragment of that redirect, so the browser session that started the exchange is the one that finishes it.

In a cross-device flow the visitor starts on a desktop browser while the wallet lives on their phone. The site renders the request as a QR code, the wallet scans it, and the wallet posts the result straight to the site's backend instead of to the browser on the desk. The desktop page then has to be told that the exchange finished, usually by polling or over a websocket, which is why a cross-device flow always involves the backend.

Both protocols assume you support both shapes. OpenID4VP names them as its two flows, and OpenID4VCI describes the same split for a Credential Offer, which can reach the holder on the device the wallet is on or through any other channel. Which one a visitor gets is decided by where they happen to be, not by a setting you choose once, so a public-facing service needs both paths to work.

The user experience differs in effort and in failure modes. Same-device is the shorter path: no second screen, no camera, no hand-off between devices. Cross-device costs a scan, but it keeps the visitor on the large screen they were already working on, and it is the only option when the wallet is not on the device doing the work. A same-device flow breaks when no wallet is installed or the deep link opens the wrong app, while a cross-device flow breaks when the code expires or the phone has no connection.

The security difference is real and it favours same-device. Because the wallet returns the response through a redirect on its own device, an attacker who copies the request has no way to collect the answer. A cross-device response travels out of band to the site's backend, so the site itself has to bind the code to the browser session that displayed it. Without that binding someone can take a code from a session they control, put it in front of a victim, and have the victim's credentials complete the attacker's login.

A QR code is also a phishing surface, because the code itself shows the reader nothing about who is asking. The wallet, not the code, has to display the verifier's identity and the exact request before anything is shared. The IETF has a dedicated best current practice for this class of attack in cross-device flows, and OpenID4VCI adds a transaction code to an offer for the same reason: the code arrives on the channel that already authenticated the holder, so an offer intercepted in transit cannot be redeemed by anyone else.