Saltar al contenido principal

Flujos same-device y cross-device explicados

Cada vez que una wallet demuestra algo a un sitio web, ambos tienen que encontrarse primero. A veces ya están en el mismo teléfono y el traspaso es un solo toque. A veces el sitio está en un escritorio y la wallet en un bolsillo, y el único puente entre ellos es un código en la pantalla. Son los flujos en el mismo dispositivo (same-device) y entre dispositivos (cross-device), y casi cualquier pregunta práctica sobre credenciales digitales se reduce a saber en cuál de los dos se encuentra.

Dos formas del mismo intercambio

Lo que los dos flujos tienen en común es todo lo que importa al negocio: se hace la misma pregunta, la misma persona la aprueba y vuelve la misma prueba. Lo que usted puede solicitar, y aquello en lo que puede confiar después, no depende del flujo en el que se encuentre.

Lo que cambia es la ruta. En uno, la wallet está a un toque de distancia y devuelve la respuesta directamente a la página que la pidió. En el otro, la respuesta viaja desde un segundo dispositivo a sus servidores, y hay que avisar a la página que la persona está mirando de que ha llegado.

El flujo en el mismo dispositivo y el flujo entre dispositivos, uno al lado del otro, paso a paso.

Mismo dispositivo

Un teléfono. Sitio web y wallet en la misma pantalla.

  1. El visitante está en el sitio desde el navegador de su teléfono y necesita demostrar algo.
  2. El sitio abre la wallet con un enlace profundo o una redirección.
  3. La wallet muestra quién pregunta y para qué, y el visitante lo aprueba.
  4. La wallet redirige al sitio con la respuesta, en la misma sesión del navegador en la que empezó todo.

Entre dispositivos

Dos dispositivos. Sitio web en el ordenador, wallet en el teléfono.

  1. El visitante está en el sitio desde el navegador de un ordenador y necesita demostrar algo.
  2. El sitio muestra un código QR que contiene la solicitud.
  3. La wallet del teléfono lo escanea, muestra quién pregunta y el visitante lo aprueba.
  4. La wallet envía la respuesta al backend del sitio, que avisa a la página del ordenador de que el intercambio ha terminado.

Cuándo ocurre cada uno

Usted no elige. Un cliente que abre su página de onboarding en el teléfono durante el trayecto al trabajo está en un flujo en el mismo dispositivo. El mismo cliente, que termina el mismo formulario en su escritorio a la mañana siguiente, está en un flujo entre dispositivos. La wallet vive en un teléfono, así que el flujo sigue allí donde ocurre el resto del trabajo.

Por eso los dos protocolos del ecosistema europeo describen ambos. La presentación, en la que usted pide a alguien que demuestre algo, nombra los dos flujos de forma explícita. La emisión, en la que usted entrega una credencial a alguien, hace la misma distinción para la oferta que la inicia: puede aparecer en el dispositivo donde está la wallet o llegar por cualquier otra vía, incluso una carta con un código impreso.

Un servicio que solo se usa dentro de su propia organización, en ordenadores gestionados, puede empezar razonablemente con un solo flujo. Todo lo que un ciudadano o un cliente alcanza por su cuenta necesita ambos, y un servicio que solo funciona de una manera se reportará como roto, no como no compatible.

Lo que cada uno le cuesta a quien lo usa

El flujo en el mismo dispositivo es el camino más corto. No hay segunda pantalla, ni cámara, ni ese momento de mirar de un dispositivo a otro, y la persona vuelve a donde empezó. Cuando falla, suele fallar pronto y a la vista: no hay ninguna wallet instalada, o el enlace abre algo que no es una wallet.

El flujo entre dispositivos cuesta un escaneo, pero aporta algo real. La persona se queda en la pantalla grande donde rellenaba un formulario largo, leía un contrato o comparaba opciones, y solo la prueba pasa al teléfono. Para cualquier cosa que exija más de un minuto de escritura, es el mejor sitio donde estar.

Sus fallos son más silenciosos y conviene tenerlos en cuenta en el diseño. Un código que caducó mientras alguien buscaba el teléfono, un teléfono sin cobertura, una cámara que no enfoca. La página que muestra el código debe indicar cuánto tiempo es válido, ofrecer uno nuevo sin perder el formulario de debajo y no dejar nunca a la persona preguntándose si ha pasado algo.

Donde realmente se diferencian: la seguridad

En un flujo en el mismo dispositivo, la respuesta vuelve por el mismo camino que siguió la persona: una redirección, en el dispositivo donde funciona la wallet, hacia la sesión del navegador que inició el intercambio. Quien copie la solicitud de su propia pantalla no tiene forma de recibir el resultado, porque se entrega en el dispositivo que dio la aprobación.

En un flujo entre dispositivos, la respuesta no vuelve por el navegador en absoluto. Va del teléfono a sus servidores, fuera de la vista de la página que mostró el código. Ahí está el hueco: si no vincula el código a la sesión que lo mostró, su servicio no puede distinguir entre la persona que tiene delante y alguien que puso ese mismo código delante de una víctima y esperó.

Ese ataque tiene nombre y remedio. El código debe pertenecer a una sola sesión, y un resultado que llegue para cualquier otra sesión debe rechazarse. Requiere un poco de reflexión en la fase de diseño y deja un agujero conocido si se omite, por eso el IETF redactó una best current practice para los flujos entre dispositivos en lugar de dejarlo en manos de cada implementación.

El segundo riesgo es el phishing, y es propio del código. Un cuadrado en blanco y negro no le dice a la persona nada sobre quién está al otro lado, así que un código impreso en una pegatina y colocado encima de uno auténtico es un ataque creíble. La defensa es que la wallet, y no el código, nombre a la organización que pregunta y enumere exactamente lo que quiere antes de compartir nada. La emisión añade un cerrojo más: una oferta puede exigir un código corto enviado por el canal que ya identificó a la persona, de modo que nadie más pueda canjear una oferta interceptada por el camino.

Qué significa esto para usted

Parte usuaria

Planifique ambos desde el principio. El trabajo adicional está en su front-end y en vincular el código a una sesión, no en una segunda integración, y añadir esa vinculación a posteriori es la parte que sale mal.

Emisor

Decida cómo llega su oferta a las personas. En pantalla junto a un inicio de sesión, en un correo electrónico o en papel: cada vía acaba en un flujo distinto, y las que salen de su canal son las que necesitan un código aparte para canjearse.

Titular de la wallet

Lea lo que le muestra la wallet, no lo que afirman la página o el código. La wallet es el único lugar que indica quién pregunta y qué quiere, y el último momento en el que puede decir que no.

Términos relacionados

Preguntas frecuentes

¿Quién decide qué flujo se usa?

La situación, no un ajuste. Si la persona ya está en el dispositivo donde tiene su wallet, el sitio le cede el paso directamente. Si está en un ordenador y la wallet está en su bolsillo, la única forma de cruzar es un código para escanear. Un servicio abierto al público se encontrará con ambos en su primera semana.

¿Admitir ambos significa construirlo todo dos veces?

No. La solicitud que usted hace y la respuesta que comprueba son las mismas en ambos casos. Lo que cambia es cómo llega la solicitud a la wallet y cómo vuelve la respuesta a su página: una redirección que sigue el navegador, o un código en pantalla más una forma de que esa página sepa que el intercambio ha terminado. En la práctica es una ruta más en su front-end, no una segunda integración.

¿Es seguro usar un código QR para esto?

Sí, si el intercambio que lo rodea está bien construido. Un código por sí solo no le dice a la persona nada sobre quién pregunta, así que deben cumplirse dos cosas: la wallet debe mostrar la identidad de la organización que pregunta antes de compartir nada, y su propio servicio debe rechazar una respuesta que llegue para una sesión distinta de la que mostró el código. Ambas son práctica habitual y ambas están recogidas en las especificaciones.

¿Una comprobación en un mostrador es un flujo entre dispositivos?

No, es un tercer caso. Tanto el flujo en el mismo dispositivo como el flujo entre dispositivos describen un intercambio por internet. Una comprobación presencial, con los dos dispositivos uno junto al otro, usa en su lugar un estándar de proximidad por Bluetooth o NFC. Para quien sostiene el teléfono parece parecido, pero nada pasa por su sitio web.

Fuentes

  1. OpenID for Verifiable Presentations, Same Device Flow y Cross Device Flow
  2. OpenID for Verifiable Credential Issuance, Credential Offer same-device y cross-device
  3. IETF Cross-Device Flows: Security Best Current Practice

Esta página tiene carácter informativo y no constituye asesoramiento legal. Para obtener orientación autorizada, consulte directamente las especificaciones de OpenID y del IETF.

Hable con nosotros sobre la integración del EUDI Wallet