Les flux same-device et cross-device expliqués
Chaque fois qu'un wallet prouve quelque chose à un site web, les deux doivent d'abord se trouver. Parfois ils sont déjà sur le même téléphone et le passage de relais tient en un seul geste. Parfois le site est sur un bureau et le wallet dans une poche, et le seul pont entre eux est un code à l'écran. Ce sont les flux same-device et cross-device, et presque toutes les questions pratiques sur les credentials numériques reviennent à savoir dans lequel des deux vous vous trouvez.
Deux formes du même échange
Ce que les deux flux ont en commun, c'est tout ce qui compte pour l'entreprise : la même question est posée, la même personne l'approuve et la même preuve revient. Ce que vous avez le droit de demander, et ce sur quoi vous pouvez vous appuyer ensuite, ne dépend pas du flux dans lequel vous vous trouvez.
Ce qui diffère, c'est le trajet. Dans l'un, le wallet est à portée de doigt et renvoie la réponse directement à la page qui l'a demandée. Dans l'autre, la réponse voyage d'un second appareil vers vos serveurs, et la page que la personne regarde doit être informée de son arrivée.
Same-device
Un seul téléphone. Site web et wallet sur le même écran.
- Le visiteur est sur le site depuis le navigateur de son téléphone et doit prouver quelque chose.
- Le site ouvre le wallet par un lien profond ou une redirection.
- Le wallet indique qui demande et dans quel but, et le visiteur donne son accord.
- Le wallet redirige vers le site avec la réponse, dans la session de navigateur qui a lancé l'échange.
Cross-device
Deux appareils. Site web sur un ordinateur, wallet sur un téléphone.
- Le visiteur est sur le site depuis le navigateur d'un ordinateur et doit prouver quelque chose.
- Le site affiche un QR code qui contient la demande.
- Le wallet du téléphone le scanne, indique qui demande, et le visiteur donne son accord.
- Le wallet envoie la réponse au backend du site, qui signale à la page de l'ordinateur que l'échange est terminé.
Quand chacun intervient
Vous ne choisissez pas. Un client qui ouvre votre page d'onboarding sur son téléphone dans les transports est dans un flux same-device. Le même client, qui termine le même formulaire à son bureau le lendemain matin, est dans un flux cross-device. Le wallet vit sur un téléphone, donc le flux suit l'endroit où se déroule le reste du travail.
C'est pourquoi les deux protocoles de l'écosystème européen décrivent les deux. La présentation, où vous demandez à quelqu'un de prouver quelque chose, nomme explicitement les deux flux. L'émission, où vous remettez un credential à quelqu'un, fait la même distinction pour l'offre qui la déclenche : elle peut apparaître sur l'appareil où se trouve le wallet, ou arriver par n'importe quelle autre voie, jusqu'à un courrier portant un code imprimé.
Un service utilisé uniquement au sein de votre organisation, sur des postes gérés, peut raisonnablement démarrer avec un seul flux. Tout ce qu'un citoyen ou un client atteint par ses propres moyens a besoin des deux, et un service qui ne fonctionne que d'une seule manière sera signalé comme défaillant plutôt que comme non pris en charge.
Ce que chacun coûte à l'utilisateur
Le same-device est le chemin le plus court. Pas de second écran, pas de caméra, pas de va-et-vient du regard entre deux appareils, et la personne revient là où elle a commencé. Quand il échoue, c'est en général tôt et de façon visible : aucun wallet installé, ou le lien ouvre quelque chose qui n'est pas du tout un wallet.
Le cross-device coûte un scan, mais apporte un vrai bénéfice. La personne reste sur le grand écran où elle remplissait un long formulaire, lisait un contrat ou comparait des options, et seule la preuve passe sur le téléphone. Pour tout ce qui demande plus d'une minute de saisie, c'est le meilleur endroit où se trouver.
Ses échecs sont plus discrets et méritent d'être anticipés dans la conception. Un code expiré pendant que quelqu'un cherchait son téléphone, un téléphone sans réseau, une caméra qui ne fait pas la mise au point. La page qui affiche le code doit indiquer sa durée de validité, en proposer un nouveau sans perdre le formulaire en dessous, et ne jamais laisser la personne se demander si quelque chose s'est passé.
Là où ils diffèrent vraiment : la sécurité
Dans un flux same-device, la réponse revient par le chemin emprunté par la personne : une redirection, sur l'appareil où tourne le wallet, vers la session de navigateur qui a lancé l'échange. Quelqu'un qui copie la demande depuis son propre écran n'a aucun moyen de recevoir le résultat, car celui-ci est livré à l'appareil qui a donné l'accord.
Dans un flux cross-device, la réponse ne repasse pas du tout par le navigateur. Elle va du téléphone à vos serveurs, hors de vue de la page qui a affiché le code. C'est là que se trouve la faille : si vous ne liez pas le code à la session qui l'a affiché, votre service ne peut pas distinguer la personne qui se trouve devant lui de quelqu'un qui a placé le même code devant une victime et attendu.
Cette attaque a un nom et une parade. Le code doit appartenir à une seule session, et un résultat qui arrive pour toute autre session doit être refusé. Cela demande un peu de réflexion à la conception et laisse une faille connue si on l'oublie, c'est pourquoi l'IETF a rédigé une best current practice pour les flux cross-device au lieu de laisser chaque implémentation s'en charger.
Le second risque est le phishing, et il tient au code lui-même. Un carré noir et blanc ne dit rien à la personne sur qui se trouve à l'autre bout, si bien qu'un code imprimé sur un autocollant et collé sur un vrai constitue une attaque crédible. La défense consiste à ce que le wallet, et non le code, nomme l'organisation qui demande et liste précisément ce qu'elle veut avant tout partage. L'émission ajoute un verrou de plus : une offre peut exiger un code court transmis par le canal qui a déjà identifié la personne, de sorte qu'une offre interceptée en chemin ne peut être utilisée par personne d'autre.
Ce que cela signifie pour vous
Partie utilisatrice
Prévoyez les deux dès le départ. Le travail supplémentaire se situe dans votre front-end et dans la liaison du code à une session, pas dans une seconde intégration, et c'est l'ajout de cette liaison après coup qui tourne mal.
Émetteur
Décidez comment votre offre atteint les gens. À l'écran à côté d'une connexion, dans un e-mail ou sur papier : chaque voie mène à un flux différent, et celles qui sortent de votre canal sont celles qui exigent un code distinct pour être utilisées.
Détenteur du wallet
Lisez ce que le wallet vous montre, pas ce que prétend la page ou le code. Le wallet est le seul endroit qui indique qui demande et ce qu'il veut, et le dernier moment où vous pouvez refuser.
Termes associés
Questions fréquentes
Qui décide du flux utilisé ?
La situation, pas un paramètre. Si la personne est déjà sur l'appareil où se trouve son wallet, le site lui passe la main directement. Si elle est sur un ordinateur et que le wallet est dans sa poche, le seul passage possible est un code à scanner. Un service ouvert au public rencontrera les deux dès sa première semaine.
Prendre en charge les deux, est-ce tout développer deux fois ?
Non. La demande que vous émettez et la réponse que vous vérifiez sont les mêmes dans les deux cas. Ce qui change, c'est la façon dont la demande atteint le wallet et dont la réponse revient à votre page : une redirection que le navigateur suit, ou un code à l'écran plus un moyen pour cette page d'apprendre que l'échange est terminé. En pratique, c'est un parcours de plus dans votre front-end, pas une seconde intégration.
Un QR code est-il sûr pour cet usage ?
Oui, si l'échange autour est correctement conçu. Un code seul ne dit rien à la personne sur l'identité de celui qui demande, donc deux conditions doivent être remplies : le wallet doit afficher l'identité de l'organisation qui demande avant tout partage, et votre propre service doit refuser une réponse qui arrive pour une autre session que celle qui a affiché le code. Ce sont deux pratiques courantes, et toutes deux figurent dans les spécifications.
Un contrôle au guichet est-il un flux cross-device ?
Non, c'est un troisième cas. Same-device et cross-device décrivent tous deux un échange par internet. Un contrôle en face à face, avec les deux appareils tenus l'un près de l'autre, utilise plutôt une norme de proximité via Bluetooth ou NFC. Pour la personne qui tient le téléphone, cela se ressemble, mais rien ne transite par votre site web.
Sources
Cette page est fournie à titre informatif et ne constitue pas un avis juridique. Pour des orientations faisant autorité, consultez directement les spécifications OpenID et IETF.