Biometría y conocimiento del pagador en el enlace dinámico

El enfoque de Corbado combina passkeys (SCA) resistentes al phishing con una pantalla controlada por el banco y un enlace dinámico del lado del servidor para cumplir con el Art. 5 de los RTS de la PSD2 (“lo que ves es lo que firmas”).

• Implementación principal (actual): Mostramos el importe y el beneficiario de la transacción en una interfaz de usuario controlada por Bison-Bank inmediatamente antes y durante la autenticación con passkey. Nuestro backend genera un desafío de un solo uso que está vinculado a una instantánea canónica de la transacción (importe, beneficiario, ID de la transacción). La respuesta solo se acepta si coincide con esa instantánea; cualquier cambio la invalida.

• Posición regulatoria: El enlace dinámico sigue siendo obligatorio para los pagos remotos incluso con passkeys (PSD2 Art. 97(2); RTS Art. 5). Los RTS no exigen que el “código de autenticación” del enlace dinámico se calcule en el dispositivo; la generación/validación en el lado del servidor es aceptable cuando se garantiza la integridad de la visualización, la especificidad y la invalidación en caso de cambio (véase también la Q&A 2020_5366 de la ABE sobre dónde se puede calcular el código).

• Seguridad y auditabilidad: Vincular una firma de passkey anclada en hardware y resistente al phishing a los datos específicos de una transacción evita la manipulación y la retransmisión, y produce una prueba sólida e irrefutable del consentimiento del pagador. Cuando sea compatible, podemos adoptar opcionalmente la Confirmación de Pago Segura (SPC) para añadir una prueba criptográfica de los detalles mostrados sin cambiar el modelo del backend.

• SCA: Dos elementos independientes de categorías distintas (conocimiento/posesión/inherencia), protegidos contra la divulgación/replicación con las mitigaciones adecuadas (RTS Arts. 6–8). Se requiere independencia (Art. 9), incluida la separación cuando se ejecutan en dispositivos multipropósito (p. ej., protecciones a nivel del sistema operativo, hardware seguro).
• Enlace dinámico (RTS Art. 5):
  • (i) el pagador es consciente del importe y el beneficiario durante la autenticación
  • (ii) el código de autenticación es único para ese importe/beneficiario
  • (iii) cualquier cambio invalida el código
  • (iv) la confidencialidad/integridad del importe, el beneficiario y el código están protegidas de extremo a extremo. Esto cumple con la intención regulatoria de “lo que ves es lo que firmas”.
• Implicación: Una autenticación de usuario reforzada por sí sola no es suficiente para los pagos. La aprobación debe estar vinculada a datos de transacción específicos con una prueba auditable de la vinculación y de lo que se le mostró al pagador (RTS Art. 5(1)(a–d)).

Aclaración — phishing vs. autorización: Las passkeys están vinculadas al origen, por lo que los dominios falsos no pueden obtener firmas válidas. Sin embargo, la PSD2 sigue requiriendo el enlace dinámico para los pagos remotos para vincular la autorización al importe y beneficiario exactos, invalidar cualquier cambio y proteger la integridad de lo que se muestra al pagador (RTS Art. 5(1)(a–d)). El enlace dinámico aborda la integridad de la autorización (incluida la sustitución por MITM/MITB/TPP), no solo el phishing.

La Opinión de la ABE de 2019 (EBA‑Op‑2019‑06) refuerza que el enlace dinámico vincula la autenticación al importe y al beneficiario, requiere la independencia de los factores y acepta las claves criptográficas vinculadas al dispositivo como posesión cuando existe una vinculación única al dispositivo. También hace hincapié en la integridad de lo que se muestra al pagador durante la autenticación. Opinión de la ABE 2019

Antes de la PSD2, muchos bancos dependían de OTP por SMS o listas de TAN impresas que a menudo no mostraban el importe o el beneficiario junto al paso de aprobación. Esa laguna facilitaba que se engañara a los clientes para que autorizaran transferencias no deseadas una vez que se robaban sus credenciales. El enlace dinámico se introdujo para cerrar esa brecha, asegurando que el pagador sea consciente del importe y el beneficiario exactos en el momento de la autenticación y haciendo que el código de autenticación sea específico para esos detalles, de modo que cualquier cambio lo invalide (RTS Art. 5(1)(a–d)). Cuando el SMS es parte del flujo, los emisores también deben garantizar la confidencialidad, autenticidad e integridad del importe/beneficiario y del código en todas las fases de la autenticación (Q&A 2018_4414; RTS Art. 5(2)). Las aprobaciones en la aplicación de hoy en día (por ejemplo, “¿Desea autorizar 100 USD a Juan Pérez mediante Face ID?”) implementan este principio de “lo que ves es lo que firmas” de una manera fácil de usar para el cliente.

Hoy en día, en los móviles, predominan dos patrones. Primero, una notificación push puede llevar al cliente a la aplicación para revisar los detalles de la transacción y aprobarla. Los supervisores han aclarado que las notificaciones push pueden servir como prueba del elemento de posesión si se implementan los controles del Artículo 7 para mitigar el uso no autorizado y prevenir la replicación, y si el proceso general cumple con los RTS; no obstante, persisten los riesgos de ingeniería social, que deben abordarse en la UX (Q&A 2019_4984; RTS Art. 7).

Segundo, las aprobaciones que utilizan la biometría nativa del dispositivo (con un PIN como alternativa) realizan la verificación del usuario localmente para desbloquear una operación de clave privada. La clave privada reside en un entorno de hardware seguro (Secure Enclave/TEE/TPM) y firma un desafío. Esto se corresponde claramente con la SCA: inherencia (biometría) más posesión demostrada por la vinculación al dispositivo y una clave criptográfica vinculada al dispositivo (EBA‑Op‑2019‑06, párrs. 25, 35–37). Para los pagos remotos, el código debe estar vinculado dinámicamente al importe y al beneficiario, y esos detalles deben mostrarse al pagador antes de la verificación del usuario (RTS Art. 5). Si ambos factores están en un mismo dispositivo, se deben implementar entornos de ejecución seguros separados y comprobaciones de integridad para que un compromiso de uno no comprometa al otro (RTS Art. 9(2)–(3)).

Bajo el capó, la biometría local no se “autentica ante el banco” directamente. En cambio, el dato biométrico (o el PIN alternativo) realiza la verificación del usuario en el dispositivo y controla el acceso a una clave privada no exportable almacenada en un módulo de seguridad respaldado por hardware. Cuando el pagador aprueba, el dispositivo utiliza esa clave privada para producir una firma digital sobre un desafío proporcionado por el banco. Si el banco deriva o asocia ese desafío con una instantánea canónica de la transacción (importe, beneficiario, identificadores), entonces la firma resultante funciona como un código de autenticación que es específico para esos detalles. Cualquier cambio invalidará el código porque la instantánea almacenada ya no coincide o, en diseños mejorados, porque la derivación del desafío cambia. La parte del conocimiento del pagador sigue siendo un requisito de UX: mostrar el importe y el beneficiario en una vista controlada por el banco inmediatamente antes de la verificación del usuario. Juntos, esto satisface los requisitos del Art. 5 de los RTS sobre conocimiento, especificidad/unicidad e invalidación en caso de cambio, mientras que los controles del Artículo 7 y la vinculación al dispositivo evidencian el elemento de posesión.

• Posesión (claves vinculadas al dispositivo y sincronizadas): Las claves privadas de las passkeys se almacenan en hardware seguro (TEE/Secure Enclave/TPM). Las passkeys vinculadas al dispositivo no son exportables, lo que se alinea con las expectativas de la ABE para una vinculación única al dispositivo (EBA‑Op‑2019‑06, párrs. 25, 35–37). Las passkeys sincronizadas también pueden evidenciar la posesión en cada autenticación, siempre que la vinculación al dispositivo y los controles anti-replicación sean efectivos; los reguladores han enfatizado la necesidad de un vínculo fiable entre el elemento y el dispositivo (EBA‑Op‑2019‑06; RTS Art. 7).
• Inherencia/conocimiento (Verificación de Usuario): La Verificación de Usuario mediante biometría (inherencia) o PIN del dispositivo (conocimiento) activa la clave localmente. Combinado con la posesión, esto es una verdadera 2FA con independencia de factores. Una brecha en uno no compromete al otro.

El enlace dinámico consiste en vincular la autenticación a la transacción. La pregunta para un banco es: si permitimos que un usuario apruebe un pago mediante una passkey (en lugar de, por ejemplo, un OTP o un dispositivo de firma), ¿podemos garantizar que esta aprobación es específica para el importe y el beneficiario previstos, y que no puede ser reutilizada o manipulada?

Hay 2 opciones para implementar el enlace dinámico con passkeys:

• Enlace del lado del servidor (estándar): Generar un desafío WebAuthn de un solo uso que el backend asocia con el importe y el beneficiario exactos. El usuario ve “X € a Y” en una vista controlada por el banco y aprueba con una passkey. La respuesta se acepta solo para esa transacción. Cualquier cambio la invalida.
• Inclusión criptográfica (mejorada): Incrustar un hash del importe/beneficiario en el desafío para que la firma se comprometa con los datos de la transacción. Esto no es requerido por los RTS, pero añade la seguridad de que incluso los intercambios en el backend fallarían la verificación.

Nota explícita de cumplimiento: Los RTS no requieren que el “código de autenticación” del enlace dinámico se calcule en el dispositivo del pagador. Un PSP puede generarlo y validarlo en el servidor siempre que el importe/beneficiario estén protegidos y cualquier cambio invalide el código (véase la Q&A 2020_5366 de la ABE sobre la ubicación/momento del código). Ese es nuestro enfoque de enlace dinámico del lado del servidor (estándar).

Ambos producen un “código de autenticación” único, no reutilizable y específico para la transacción. La principal advertencia es el conocimiento del pagador: WebAuthn por sí mismo no prueba lo que se mostró. La integridad de la visualización debe provenir de una interfaz de usuario controlada por el banco.

El Artículo 5 de los RTS requiere que el pagador vea el importe y el beneficiario durante la autenticación. WebAuthn no certifica lo que se mostró. En teoría, si la aplicación o el sistema operativo están comprometidos, un usuario podría ser engañado mientras el autenticador sigue firmando. A continuación, analizaremos en detalle cómo se desarrolla este riesgo en la realidad y por qué no es un riesgo de seguridad real, sino más bien una cuestión de interpretación de la regulación.

Controles de integridad de la visualización que aplicamos:

• La vista controlada por el banco muestra el importe + beneficiario: bloqueamos la invocación de la passkey si la vista está oculta o desenfocada.
• Detección de superposiciones/manipulaciones en la aplicación/web: no se solicitan passkeys desde iframes ocultos.
• Control de integridad/atestación del dispositivo: denegar o escalar ante señales de que el dispositivo está rooteado/con jailbreak/comprometido.
• Aprobación atómica contra una instantánea del importe/beneficiario guardada en el servidor: se requiere un nuevo desafío ante cualquier cambio de parámetro.

Sobre la inclusión criptográfica: Las extensiones de “visualización de transacción” de WebAuthn (SPC) no tienen un amplio soporte hoy en día. Nuestra base portátil es la vinculación del lado del servidor, reforzada derivando el desafío de la instantánea de la transacción (p. ej., H(importe ‖ beneficiario ‖ ID de transacción ‖ nonce)) para que la firma se comprometa con esos valores.

Ambos patrones utilizan criptografía de clave pública con claves de dispositivo no exportables, y ambos dependen de la verificación local del usuario para desbloquear la operación de firma. En ambos, el banco garantiza el conocimiento del pagador mostrando el importe y el beneficiario en una vista controlada por el banco inmediatamente antes de la verificación del usuario, y asegura la especificidad vinculando el código de autenticación a esos detalles, invalidándolo ante cualquier cambio (RTS Art. 5(1)(a–d)). Los RTS son tecnológicamente neutros y no requieren que el importe/beneficiario se muestren dentro de un modal biométrico del sistema operativo; requieren la visualización al pagador y la vinculación del código (RTS Art. 5). Cuando ambos elementos de la SCA se ejecutan en un dispositivo, los requisitos de integridad y separación del Artículo 9 se aplican por igual (RTS Art. 9(2)–(3)). Finalmente, la ubicación del cálculo del enlace dinámico es flexible: puede realizarse en el lado del servidor si se preserva la integridad y cualquier cambio invalida el código (Q&A 2020_5366). Estas son las mismas condiciones bajo las cuales los reguladores ya aceptan la biometría local con PKI; por lo tanto, las passkeys, implementadas con los mismos controles de conocimiento del pagador y vinculación, deberían ser aceptadas sobre una base equivalente.

Entonces, ¿las passkeys simples según el estándar WebAuthn cumplen la intención del enlace dinámico? Parcialmente:

• Ataques MITM/de red: Sí. La vinculación al origen y las firmas por desafío evitan la manipulación y la repetición.
• Integridad de la transacción: Sí. La asociación en el servidor o el hashing del desafío aseguran que solo el importe/beneficiario original se verificará.
• Consentimiento del pagador: Más difícil. Las passkeys carecen de una visualización a nivel del autenticador. El engaño en la interfaz de usuario en dispositivos comprometidos podría ser posible. Se debe construir algo adicional para garantizar el consentimiento del pagador.

Por qué el enlace dinámico sigue siendo necesario con las passkeys

• Legal: El Art. 97(2) de la PSD2 y el Art. 5 de los RTS exigen el enlace dinámico para toda iniciación de pago remoto. No hay exenciones para los métodos resistentes al phishing.
• Seguridad: Las passkeys eliminan el phishing entre orígenes, pero no evidencian por sí mismas lo que se le mostró al pagador. El enlace dinámico + los controles de integridad de la visualización garantizan que el importe/beneficiario específicos que el usuario vio son los que el banco ejecuta, y que cualquier cambio invalida la aprobación.

En resumen, las passkeys pueden satisfacer el enlace dinámico cuando están estrictamente vinculadas a los datos de la transacción y se combinan con mecanismos de visualización fiables. El desafío residual es demostrar lo que el usuario realmente vio.

Corbado ofrece una solución compatible con el enlace dinámico que aborda explícitamente las consideraciones de consentimiento del pagador mencionadas anteriormente.

// TODO: PROPORCIONAR MOCKUPS DE KARUNA Y DESCRIBIRLOS

Flujo del proceso:

• Una pantalla controlada por el banco muestra al pagador el importe y el beneficiario exactos. No se muestra ninguna solicitud de passkey a menos que esta vista esté visible.
• Autenticación: el cliente invoca WebAuthn con un desafío de un solo uso y vinculado para la transacción canónica. El autenticador realiza la verificación del usuario (biometría o PIN del dispositivo) y firma sobre el desafío y el origen.
• Verificación en el servidor: el backend verifica el hash del RP ID y el origen, hace coincidir el desafío con la transacción almacenada, comprueba las banderas de UV, impone el uso único y la caducidad, y compara la instantánea almacenada del importe/beneficiario.
• Aprobación y auditoría: solo entonces se aprueba atómicamente la transacción. Cualquier discrepancia/cambio se rechaza y requiere una nueva autenticación. Se persiste un registro de auditoría inmutable (ID de credencial, authenticatorData, clientDataJSON, firma, desafío e importe/beneficiario canónicos), opcionalmente encadenado con hash como prueba de no manipulación.
• Control de integridad del dispositivo: Evaluar las señales de integridad y atestación del dispositivo: denegar o escalar si el dispositivo está rooteado/con jailbreak/comprometido.
• Canonización del beneficiario: Mostrar una etiqueta amigable (p. ej., “ACME GmbH”), pero vincular y verificar contra un identificador canónico del beneficiario (p. ej., IBAN/BIC u otro esquema único).

Detalles técnicos:

• Backend: crear un objeto de transacción con datos canónicos (p. ej., moneda/decimales normalizados; IBAN/beneficiario canónicos). Generar un desafío de corta duración que se comprometa con estos valores (p. ej., H(importe||beneficiario||ID de transacción||nonce)); almacenarlo como pendiente; exponer solo ID opacos al cliente.
• Cliente/autenticador: mostrar los detalles del pagador en una vista controlada por el banco; invocar WebAuthn (RP ID = dominio de Bison) solo cuando esté visible; requerir la verificación del usuario; el autenticador firma el desafío + origen según WebAuthn.
• Verificación/finalización: validar firma, hash del RP ID, origen/tipo, banderas de UV; anti-repetición/caducidad; comparar la instantánea inmutable del importe/beneficiario; aprobar atómicamente; persistir el registro de auditoría.
• Derivar el desafío de la instantánea:: challenge = H(importe ‖ beneficiarioCanónico ‖ ID de transacción ‖ nonce)

Políticas de UX:

• Énfasis claro en el importe/beneficiario; controles de confirmación/cancelación accesibles; tiempos de espera cortos; reintentos graduales siempre usando un nuevo desafío; recibos inmediatos (p. ej., “Aprobaste X € a Y”). Bloquear la solicitud de passkey si la pantalla está oculta y advertir si los parámetros cambian antes de firmar.
• Detectar superposiciones/contenido oculto: nunca mostrar una solicitud de passkey si la vista de la transacción no está visible. Rechazar si los parámetros cambian a mitad del flujo y reiniciar con un nuevo desafío.

Nota de cumplimiento: Este diseño de extremo a extremo cumple con el Art. 5 de los RTS: conocimiento del pagador (pantalla controlada por el banco), especificidad y unicidad (código de un solo uso vinculado al importe/beneficiario), invalidación en caso de cambio (verificaciones estrictas en el servidor) y confidencialidad/integridad del importe/beneficiario y el código en todas las fases (RTS Art. 5(1)(a–d), 5(2); véase también la Q&A 2018_4414 para la integridad del SMS). La independencia de factores (Arts. 7–9) se preserva mediante la posesión vinculada al dispositivo y la verificación local del usuario en dispositivos multipropósito con las protecciones adecuadas (RTS Art. 9(2)–(3)).

Nota: para flujos web, Corbado adoptará opcionalmente la Confirmación de Pago Segura si/cuando Apple ofrezca un soporte amplio, añadiendo una pantalla de confianza mediada por el navegador que atestigua criptográficamente el importe y el beneficiario.

Preocupación: Ataques de phishing Respuesta: Las passkeys son resistentes al phishing por diseño: están vinculadas al origen legítimo y no implican secretos compartidos, por lo que las credenciales no pueden ser recolectadas en un sitio falso, a diferencia de los OTP. Un atacante que redirige el tráfico a un dominio de apariencia similar no puede obtener una firma válida para el origen del banco. El enlace dinámico contribuye menos en este vector, pero sigue siendo obligatorio para garantizar que cualquier aprobación sea única para el importe y el beneficiario previstos. Medidas complementarias (educación sobre phishing, separación clara entre aprobaciones de inicio de sesión y de pago, puntuación de anomalías/riesgos para contextos de pago inusuales) reducen aún más la exposición.

Preocupación: Ingeniería social / Fraude de Pago por Empuje Autorizado (APP) Respuesta: Ningún autenticador puede evitar por completo que un usuario autorice un pago bajo falsas pretensiones (p. ej., estafas de la “cuenta segura”). El enlace dinámico garantiza que el usuario vea explícitamente al beneficiario y el importe y proporciona una prueba sólida de consentimiento, pero no puede anular la decisión de un pagador convencido. Las compensaciones incluyen advertencias contextuales (nuevo beneficiario, primera transferencia grande), períodos de reflexión o ejecución diferida para beneficiarios de alto riesgo, verificación más sólida del beneficiario y comprobaciones adicionales (confirmación extra) ante señales de riesgo. Las notificaciones post-pago y los canales de disputa rápidos ayudan a detectar y contener el daño. Añadimos advertencias contextuales en tiempo real (p. ej., nuevo beneficiario, primera transferencia grande), períodos de reflexión para beneficiarios de alto riesgo, una verificación del beneficiario más sólida y notificaciones post-pago (“Aprobaste X € a Y”) para acelerar la detección y la respuesta.

Preocupación: Malware o compromiso del dispositivo Respuesta: Las claves privadas son no exportables y requieren verificación local del usuario para cada firma, por lo que el malware no puede simplemente exfiltrar las credenciales. El riesgo realista es el engaño en la interfaz de usuario en un sistema operativo totalmente comprometido. Se mitiga con una interfaz de usuario segura/verificada (p. ej., confirmaciones protegidas), comprobaciones de integridad/atestación del dispositivo y bloqueo de dispositivos de alto riesgo, y confirmaciones de confianza como SPC o una extensión de confirmación cuando esté disponible. Si aparecen indicadores de compromiso (detección de superposiciones, root/jailbreak), se utiliza una re-verificación fuera de banda o se deniega la ejecución. Ningún método para el consumidor es perfecto en un dispositivo totalmente controlado por un atacante, pero estos controles reducen drásticamente la ventana de oportunidad.

Preocupación: Man‑in‑the‑browser / Secuestro de sesión Respuesta: Las extensiones maliciosas o los scripts inyectados pueden iniciar acciones en el origen legítimo. Las passkeys vinculadas al origen detienen el phishing entre sitios. El enlace dinámico asegura que las ediciones ocultas al importe/beneficiario fallen. Reforzamos el canal mediante controles CSP/anti-manipulación y requiriendo un desafío nuevo y de un solo uso para cada confirmación.

Preocupación: Amenaza interna o manipulación del lado del servidor Respuesta: La respuesta de autenticación está vinculada de forma única al importe/beneficiario original, por lo que cualquier sustitución del lado del servidor falla la validación. Se mantienen registros de vinculación inmutables y a prueba de manipulaciones (desafío, credencial, firma e importe/beneficiario canónicos) para auditoría/no repudio. Se aplican la separación de funciones y los controles de cuatro ojos en las rutas críticas de procesamiento de pagos para reducir el riesgo interno.

Preocupación: Dispositivos robados / Robo de credenciales Respuesta: La mera posesión del dispositivo es insuficiente: se requiere la verificación del usuario (biometría/PIN) para cada firma, con límites de intentos y bloqueos a nivel del sistema operativo. Cada pago requiere un desafío nuevo y específico de la transacción; los tokens de sesión genéricos no pueden autorizar pagos arbitrarios. Adiciones como la revocación remota de dispositivos, la verificación adicional en el uso de un nuevo dispositivo, las comprobaciones de geovelocidad y las notificaciones (“Autorizaste X € a Y”) restringen aún más el abuso.

En general: las passkeys reducen materialmente los riesgos de phishing y repetición; el enlace dinámico sigue siendo esencial para garantizar la integridad de la transacción, vincular las aprobaciones al importe/beneficiario y proporcionar una prueba sólida de consentimiento informado en los escenarios de amenaza restantes.

Pregunta 1: ¿Cómo podemos demostrar que el usuario realmente vio y aceptó el importe y el beneficiario al usar una passkey? Respuesta: Forzamos la visualización al pagador en una vista controlada por el banco y vinculamos la aprobación a una instantánea del lado del servidor del importe/beneficiario. La aserción de la passkey (authenticatorData, clientDataJSON, firma) se acepta solo para el desafío derivado de esa instantánea; cualquier cambio requiere un nuevo desafío. Nuestra auditoría a prueba de manipulaciones vincula la aserción a “X € para el Beneficiario-ID Y” y registra que nuestro sistema no habría procedido si los detalles difirieran. Cuando es compatible, SPC añade evidencia criptográfica de que el usuario confirmó los detalles mostrados.

Pregunta 1: ¿Cómo podemos demostrar que el usuario realmente vio y aceptó el importe y el beneficiario al usar una passkey? Respuesta: Esta es esencialmente la cuestión del no repudio. Bajo la PSD2, el enlace dinámico se diseñó para asegurar que el usuario es consciente de lo que está aprobando. Con una passkey, la evidencia que conservamos es la firma criptográfica (código de autenticación) y los datos asociados (a qué importe/beneficiario estaba vinculada en nuestro servidor). Por política, mostramos los detalles de la transacción al usuario en la aplicación o página web antes de que se autentique. Registramos esa pantalla/vista y la posterior autenticación exitosa con passkey para esa transacción específica. En caso de disputa, podemos demostrar que el dispositivo del usuario produjo una firma válida para un desafío que estaba asociado con (p. ej.) “100 € a ACME Corp.” y que nuestro sistema no habría procedido si algún detalle fuera diferente. Nuestro cumplimiento se basa en un registro seguro: nos aseguramos de que nuestros sistemas sean a prueba de manipulaciones al vincular la respuesta de la passkey a los datos de la transacción.

Pregunta 2: ¿Qué pasa si el dispositivo o el sistema operativo están comprometidos? ¿Puede el malware manipular la transacción o el proceso de la passkey? Respuesta: El compromiso del dispositivo es una amenaza crítica en cualquier escenario de banca digital. Si el sistema operativo es malicioso, podría intentar engañar al usuario o secuestrar procesos. Sin embargo, incluso en este peor de los casos, las passkeys mantienen algunas protecciones clave. La clave privada no puede ser extraída por el malware. El malware tampoco puede suplantar al usuario ante el banco, porque no puede producir la firma de la passkey sin la biometría/PIN del usuario. Lo máximo que podría hacer es presionar al usuario para que autentique algo bajo falsas pretensiones. El enlace dinámico ayuda aquí al requerir comprobaciones de integridad: el malware no puede cambiar silenciosamente los detalles de la transacción después del hecho; si lo hace, la firma no se verificará. El punto más débil es la pantalla/interfaz de usuario: un troyano sofisticado podría alterar lo que el usuario ve (p. ej., mostrar “ACME Corp” mientras la transacción subyacente en realidad va a otro beneficiario). Esto no es trivial, especialmente si la aplicación del banco utiliza marcos de interfaz de usuario seguros, pero es concebible. Dicho todo esto, si detectamos signos de compromiso del dispositivo (comportamiento inusual, firmas de malware conocidas, etc.), recurriríamos a una verificación fuera de banda o denegaríamos la transacción. En resumen: Ninguna solución es 100% segura si el dispositivo del usuario está totalmente controlado por un atacante. Las passkeys + el enlace dinámico reducen drásticamente la superficie de ataque (un atacante no puede simplemente redirigir credenciales o alterar datos de la red; tendría que engañar al usuario en tiempo real). Si el sistema operativo estuviera comprometido, el enlace dinámico al menos asegura que cualquier discrepancia entre lo que debería ser y lo que se aprueba sea detectada por nuestro backend.

Pregunta 3: Si se utiliza un dato biométrico para desbloquear la passkey, ¿se considera uno o dos factores? ¿Estamos cumpliendo la regla de los 2 factores? Respuesta: Un dato biométrico por sí solo no es suficiente para la SCA; es solo un factor de inherencia. Sin embargo, en una implementación de passkey, el dato biométrico no está solo: la posesión del dispositivo es el otro factor. El dato biométrico del usuario desbloquea la clave privada almacenada en el dispositivo. Posesión e inherencia son dos categorías distintas. Esto es análogo a cómo muchas aplicaciones bancarias ya cumplen con la SCA: tienes el teléfono (posesión) y usas tu huella dactilar o tu cara para desbloquear la aplicación (inherencia). La ABE ha reconocido explícitamente las combinaciones de vinculación de dispositivo más biometría como SCA conforme. El escenario de la passkey es exactamente esa combinación. Si el usuario opta por usar un PIN en lugar de la biometría para desbloquear la passkey, entonces es posesión + conocimiento, también conforme. Exigimos la verificación del usuario en todas las operaciones con passkey (lo que significa que el usuario debe proporcionar su biometría/PIN cada vez), por lo que no hay ninguna situación en la que solo tener el dispositivo sea suficiente. Por lo tanto, cada autorización de pago mediante passkey es un evento de dos factores según las definiciones de la PSD2.

Pregunta 4: ¿Podría un atacante reutilizar una autenticación con passkey o eludir de alguna manera el enlace dinámico manipulando los datos en tránsito? Respuesta: No. Aquí es donde las passkeys y el enlace dinámico funcionan juntos de manera sólida. Cada autenticación WebAuthn produce una firma única que está vinculada al desafío (que generamos por transacción) y está limitada a nuestro dominio. Un atacante no puede reutilizar esa firma para una transacción diferente. La firma misma incorpora el nonce del desafío y solo es válida para aquello para lo que se emitió originalmente. Si un atacante interceptara la comunicación de red, no podría alterar el importe o el beneficiario sin invalidar la firma (ya que el desafío o el contexto de la transacción ya no coincidirían). Esta es efectivamente la protección contra MITM que discutimos. Además, las firmas de passkey incluyen datos de origen: no se verificarán si no se envían a nuestro sitio web/aplicación de origen exacto, por lo que el phishing o la redirección no funcionarán. En resumen, cualquier intento de manipulación invalida el código de autenticación, según las reglas del enlace dinámico. Esto es en realidad más seguro que algunos flujos actuales basados en OTP, donde los usuarios a veces aprueban un código genérico y existe el riesgo de que la solicitud haya sido manipulada. Con las passkeys, vinculamos criptográficamente la autenticación del usuario a la sesión/transacción específica.

Pregunta 5: ¿Existen opiniones regulatorias conocidas sobre WebAuthn/passkeys para SCA? ¿Estamos seguros de que los reguladores aceptarán las passkeys como conformes? Respuesta: Por ahora, la ABE no ha publicado explícitamente opiniones sobre WebAuthn o el término “passkeys” en sus Q&A u orientaciones. Sin embargo, basándose en los principios que han establecido, las passkeys encajan claramente dentro de los métodos aceptables. La opinión de la ABE de 2019 esencialmente anticipó enfoques similares a FIDO2: para la posesión, mencionan explícitamente el “intercambio de claves pública/privada” con una vinculación de dispositivo adecuada como prueba de posesión. Una passkey de WebAuthn es exactamente eso: un par de claves pública/privada, con la mitad privada vinculada de forma segura al dispositivo. También dieron el visto bueno a la “firma generada por un dispositivo” como una prueba de posesión válida. Así que, aunque no usaron el término passkey, el método está cubierto por sus ejemplos. También hemos observado que los principales actores de pagos en Europa están avanzando con implementaciones de passkeys (p. ej., PayPal), lo que indica un nivel de confianza en que esto es conforme a la PSD2. Este ejemplo demuestra que las passkeys están siendo aceptadas como parte de flujos SCA conformes, siempre que se cumplan el enlace dinámico y los requisitos generales.

Pregunta 6: ¿Seguimos necesitando el enlace dinámico si las passkeys son resistentes al phishing? Respuesta: Sí. Las passkeys eliminan el phishing entre orígenes, pero la PSD2 sigue exigiendo el enlace dinámico para la iniciación de pagos remotos. El enlace dinámico vincula el importe y el beneficiario específicos al resultado de la SCA e invalida cualquier cambio, abordando la integridad de la autorización más allá del phishing (p. ej., sustitución MITM/MITB/TPP).

La solución de Corbado es compatible con el enlace dinámico y la PSD2. La visualización al pagador previa a la autenticación, el desafío de un solo uso vinculado al importe y al beneficiario, la verificación estricta en el servidor y la auditoría inmutable satisfacen conjuntamente los requisitos del Art. 5 de los RTS sobre el conocimiento del pagador, la unicidad/especificidad, la invalidación en caso de cambio y la integridad/confidencialidad. La independencia de los factores se preserva a través de la posesión vinculada al dispositivo y la verificación del usuario (biometría o PIN), en línea con la orientación de la ABE.

En comparación con los métodos actuales de OTP/SMS, Corbado ofrece resultados de seguridad y de usuario materialmente mejores: resistencia al phishing y a la retransmisión, prevención de la manipulación silenciosa de parámetros, pruebas irrefutables más sólidas y una menor fricción a través de la verificación de usuario en el dispositivo. Los riesgos residuales (p. ej., ingeniería social, dispositivos comprometidos) se mitigan con controles concretos y son más limitados que con los métodos heredados. Para la web, Corbado puede adoptar SPC cuando el soporte de la plataforma (notablemente Apple) sea amplio, añadiendo una prueba criptográfica de la visualización sin cambiar la postura de cumplimiento fundamental.

En resumen, la autorización de transacciones basada en passkeys de Corbado cumple con la letra y el espíritu del enlace dinámico de la PSD2 y mejora la resiliencia al fraude y la auditabilidad en comparación con los enfoques heredados, al tiempo que mantiene un camino claro hacia futuras mejoras (SPC) a medida que el ecosistema madura.

En la práctica, las passkeys satisfacen el enlace dinámico cuando hacemos tres cosas: mostramos el importe y el beneficiario al pagador antes de la verificación del usuario; generamos un código de autenticación que es específico para esos detalles exactos; e invalidamos el código ante cualquier cambio (RTS Art. 5(1)(a–d)). Esto refleja los principios que los reguladores ya aceptan para la biometría local, con la comodidad añadida de que las passkeys son nativas del sistema operativo y funcionan en canales web y de aplicaciones sin una aplicación adicional. Combinadas con la vinculación al origen, no muestran solicitudes falsificadas; solo las solicitudes legítimas del sitio o aplicación original aparecen al usuario.