Flujo same-device frente a cross-device

En un flujo en el mismo dispositivo, la wallet y el sitio web o la app están en el mismo teléfono. El sitio cede el paso al visitante con un enlace profundo o una redirección, la wallet se abre, la persona aprueba lo que se le pide y la wallet la devuelve al sitio por el mismo camino por el que llegó. OpenID4VP devuelve la presentación en el fragmento de esa redirección, de modo que la sesión del navegador que inició el intercambio es la que lo termina.

En un flujo entre dispositivos, el visitante empieza en el navegador de un ordenador mientras la wallet está en su teléfono. El sitio muestra la solicitud como un código QR, la wallet lo escanea y envía el resultado directamente al backend del sitio en lugar de al navegador del escritorio. Después hay que avisar a la página del ordenador de que el intercambio ha terminado, normalmente mediante polling o un websocket, y por eso un flujo entre dispositivos siempre implica al backend.

Ambos protocolos dan por hecho que usted admite las dos formas. OpenID4VP las nombra como sus dos flujos, y OpenID4VCI describe la misma división para un Credential Offer, que puede llegar al titular en el dispositivo donde está la wallet o por cualquier otro canal. El flujo que recibe un visitante depende de dónde se encuentre en ese momento, no de un ajuste que usted elige una vez, así que un servicio abierto al público necesita que funcionen las dos rutas.

La experiencia de usuario difiere en esfuerzo y en formas de fallar. El flujo en el mismo dispositivo es el camino más corto: sin segunda pantalla, sin cámara, sin traspaso entre dispositivos. El flujo entre dispositivos cuesta un escaneo, pero mantiene al visitante en la pantalla grande en la que ya estaba trabajando, y es la única opción cuando la wallet no está en el dispositivo que se está usando. Un flujo en el mismo dispositivo falla cuando no hay ninguna wallet instalada o el enlace profundo abre la app equivocada, mientras que un flujo entre dispositivos falla cuando el código caduca o el teléfono no tiene conexión.

La diferencia de seguridad es real y favorece al flujo en el mismo dispositivo. Como la wallet devuelve la respuesta mediante una redirección en su propio dispositivo, un atacante que copie la solicitud no tiene forma de recoger la respuesta. Una respuesta entre dispositivos viaja fuera de banda hasta el backend del sitio, así que el propio sitio debe vincular el código a la sesión del navegador que lo mostró. Sin esa vinculación, alguien puede tomar un código de una sesión que controla, ponerlo delante de una víctima y hacer que las credenciales de la víctima completen el inicio de sesión del atacante.

Un código QR es además una superficie de ataque para el phishing, porque el propio código no muestra al lector nada sobre quién pregunta. Es la wallet, y no el código, la que debe mostrar la identidad del verificador y la solicitud exacta antes de compartir nada. El IETF tiene una best current practice dedicada a este tipo de ataques en los flujos entre dispositivos, y OpenID4VCI añade por el mismo motivo un código de transacción a la oferta: ese código llega por el canal que ya autenticó al titular, de modo que nadie más puede canjear una oferta interceptada por el camino.