Flux same-device vs cross-device

Dans un flux same-device, le wallet et le site web ou l'application sont sur le même téléphone. Le site passe la main au visiteur par un lien profond ou une redirection, le wallet s'ouvre, la personne approuve ce qui est demandé, et le wallet la renvoie vers le site par le chemin d'où elle venait. OpenID4VP renvoie la présentation dans le fragment de cette redirection, de sorte que la session de navigateur qui a lancé l'échange est aussi celle qui le termine.

Dans un flux cross-device, le visiteur commence dans le navigateur d'un ordinateur alors que le wallet se trouve sur son téléphone. Le site affiche la demande sous forme de QR code, le wallet le scanne et envoie le résultat directement au backend du site plutôt qu'au navigateur sur le bureau. La page de l'ordinateur doit ensuite être informée que l'échange est terminé, généralement par polling ou via un websocket. C'est pourquoi un flux cross-device implique toujours le backend.

Les deux protocoles partent du principe que vous prenez en charge les deux formes. OpenID4VP les nomme comme ses deux flux, et OpenID4VCI décrit la même distinction pour un Credential Offer, qui peut atteindre le détenteur sur l'appareil où se trouve le wallet ou par tout autre canal. Le flux qu'obtient un visiteur dépend de l'endroit où il se trouve, pas d'un paramètre choisi une fois pour toutes. Un service ouvert au public a donc besoin que les deux parcours fonctionnent.

L'expérience utilisateur diffère par l'effort demandé et par les modes d'échec. Le same-device est le chemin le plus court : pas de second écran, pas de caméra, pas de passage d'un appareil à l'autre. Le cross-device coûte un scan, mais il garde le visiteur sur le grand écran où il travaillait déjà, et c'est la seule option quand le wallet n'est pas sur l'appareil utilisé. Un flux same-device échoue quand aucun wallet n'est installé ou que le lien profond ouvre la mauvaise application, un flux cross-device échoue quand le code expire ou que le téléphone n'a pas de connexion.

La différence de sécurité est réelle et elle favorise le same-device. Comme le wallet renvoie la réponse par une redirection sur son propre appareil, un attaquant qui copie la demande n'a aucun moyen de récupérer la réponse. Une réponse cross-device transite hors bande vers le backend du site, donc le site doit lui-même lier le code à la session de navigateur qui l'a affiché. Sans cette liaison, quelqu'un peut prendre un code issu d'une session qu'il contrôle, le présenter à une victime et laisser les credentials de la victime finaliser la connexion de l'attaquant.

Un QR code est aussi une surface d'attaque pour le phishing, car le code lui-même ne montre rien au lecteur sur qui demande. C'est le wallet, et non le code, qui doit afficher l'identité du vérificateur et la demande exacte avant tout partage. L'IETF a publié une best current practice dédiée à cette catégorie d'attaques dans les flux cross-device, et OpenID4VCI ajoute pour la même raison un code de transaction à une offre : ce code arrive par le canal qui a déjà authentifié le détenteur, si bien qu'une offre interceptée en chemin ne peut être utilisée par personne d'autre.