Vinculación dinámica con passkeys: Confirmación de Pago Segura (SPC)

Want to learn how top banks deploy passkeys? Get our 80-page Banking Passkeys Report (incl. ROI insights). Trusted by JPMC, UBS & QNB.

Get Report

En nuestra completa serie de cuatro partes (parte 1, parte 2, parte 3 y parte 4) sobre la PSD2, exploramos cómo las passkeys se integran con las medidas de Autenticación Reforzada de Cliente (SCA) introducidas por la PSD2. Nos centramos específicamente en los elementos de autenticación requeridos por la SCA para acceder a aplicaciones bancarias. Los requisitos de la SCA no solo se aplican al acceso a aplicaciones, sino también a la iniciación y firma de transacciones de pago electrónico a distancia. Además, estos requisitos exigen el uso de un mecanismo conocido como vinculación dinámica. En este artículo, explicaremos qué es la vinculación dinámica y examinaremos cómo las passkeys pueden utilizarse eficazmente para implementar este mecanismo, tanto hoy como en el futuro.

La vinculación dinámica es un requisito de seguridad bajo la directiva PSD2 y su adenda de implementación, las Normas Técnicas de Regulación (RTS, por sus siglas en inglés). El concepto se introdujo para mejorar la seguridad de los pagos electrónicos, asegurando que cada transacción esté conectada de forma única a un importe específico y a un beneficiario específico mediante un código de autenticación. Esta vinculación impide cualquier modificación de los detalles de la transacción una vez que ha sido autenticada por el pagador, reduciendo así el riesgo de fraude. Los pagos electrónicos incluyen transferencias bancarias en software de banca online, pero también pagos con tarjeta de crédito en sitios de merchants.

Según la Directiva PSD2 y las RTS que la acompañan, la vinculación dinámica se define como un proceso que garantiza que "el código de autenticación generado sea específico para el importe y el beneficiario acordados por el pagador al iniciar la transacción de pago electrónico" (Artículo 97(2) de la PSD2). Esto significa que cualquier cambio en los detalles del pago invalidaría el código de autenticación, requiriendo una nueva autenticación.

La vinculación dinámica es crucial en la PSD2, ya que aborda directamente los riesgos de seguridad asociados con las transacciones electrónicas remotas, que son particularmente vulnerables a diferentes tipos de fraude, como los ataques de intermediario (man-in-the-middle).

Al asegurar la transacción de esta manera, la vinculación dinámica reduce significativamente la posibilidad de transacciones no autorizadas.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

El Artículo 5 de las RTS amplía los requisitos para el código de autenticación en la vinculación dinámica. Estos requisitos incluyen:

• Conciencia del pagador: El pagador es informado del importe de la transacción de pago y del beneficiario.

• El código de autenticación es único: El código de autenticación generado para cada transacción debe ser único y no debe ser reutilizable para ninguna otra transacción.

• El código de autenticación es específico: Los códigos que se generan y el código que se acepta deben ser específicos para el importe de la transacción y la identidad del beneficiario, tal como lo confirma el pagador. Cualquier cambio en el importe o el beneficiario resulta en la invalidación del código de autenticación.

• Transmisión segura: Se mantiene la confidencialidad, autenticidad e integridad del importe de la transacción y del beneficiario durante todas las fases de la autenticación, incluyendo la generación, transmisión y uso del código de autenticación.

Con estos requisitos técnicos de la vinculación dinámica establecidos, en la siguiente sección veremos cómo las passkeys pueden ayudar como nueva tecnología. Exploraremos su potencial para agilizar y asegurar los procesos de autenticación de pagos, haciendo que la vinculación dinámica no solo sea más robusta, sino también más fácil de usar.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Las empresas confían en Corbado para proteger a sus usuarios y hacer que los inicios de sesión sean más fluidos con passkeys. Obtén tu consulta gratuita sobre passkeys ahora.

Obtén una consulta gratuita

Primero, analicemos las diferentes opciones sobre cómo se pueden usar las passkeys en la vinculación dinámica.

En este enfoque, la passkey misma actúa como una aserción criptográfica que se utiliza directamente como código de autenticación. El desafío emitido durante el proceso de la transacción se genera para reflejar específicamente los detalles de la transacción, como el importe y el beneficiario, y se almacena junto con esa información. Cuando el usuario autoriza la transacción usando su passkey, se genera una firma única y criptográficamente segura que puede ser verificada y almacenada junto con la transacción. Esta respuesta no solo sirve como un factor de autenticación robusto, sino que también vincula directamente la aprobación a los detalles específicos de la transacción, cumpliendo estrictamente con los requisitos de la PSD2 para la vinculación dinámica.

Become part of our Passkeys Community for updates & support.

Join

Una integración más avanzada implica codificar detalles adicionales de la transacción en el propio desafío de WebAuthn (lo que técnicamente no es requerido por la PSD2/RTS). Este método sugiere incorporar un hash criptográfico del beneficiario y el importe, junto con otros datos aleatorios, en el desafío. Al hacer esto, el proceso de autenticación no solo verifica la identidad del usuario a través de la passkey, sino que también afirma criptográficamente la integridad de los detalles de la transacción. Este enfoque ofrece una capa adicional de seguridad al garantizar que cualquier manipulación del importe o los detalles del beneficiario sería detectable en el punto del pago final. La prueba criptográfica se convierte en una parte inmutable del código de autenticación, mejorando la confianza y la seguridad en entornos de transacciones de alto riesgo (más información aquí).

Analicemos las limitaciones y desafíos de estas dos opciones.

Una de las limitaciones de usar passkeys en el contexto de la vinculación dinámica, particularmente para la autenticación de pagos, es la falta de documentación concreta o garantía de que el pagador ha sido informado con precisión sobre la información del beneficiario.

Aunque las passkeys proporcionan un método seguro para la autenticación de usuarios, no verifican inherentemente si todos los detalles de la transacción, especialmente los relativos al beneficiario, se han mostrado correctamente al pagador.

Este problema no es exclusivo de las passkeys; es un desafío común en varios sistemas de pago en línea. Asegurar que el pagador sea plenamente consciente y consienta todos los detalles de la transacción antes de iniciar el pago es crucial para mantener la confianza y la seguridad.

La limitación más significativa de integrar passkeys en la vinculación dinámica surge en la distinción entre el registro de primera parte y de tercera parte.

¿Qué es un contexto de pago de primera parte?

✔️ En el contexto de pago de primera parte, el usuario interactúa directamente con el issuer / banco en su servicio de internet y dominio. Las passkeys se pueden registrar y autenticar sin problemas. Un ejemplo podría ser un banco que registra una passkey en su propio sitio web y la utiliza para autorizar una iniciación de pago desde su software de banca online. Aquí, las passkeys funcionan perfectamente. El banco puede garantizar que la passkey se utilice dentro de su dominio, manteniendo el control sobre el entorno de pago y la seguridad de la transacción.

Consulta nuestra publicación de blog sobre la implementación de passkeys de Mastercard en un contexto de pago de primera parte.

¿Qué es un contexto de pago de tercera parte?

En el contexto de pago de tercera parte, el usuario se encuentra en la página de un merchant en el proceso de pago en un dominio diferente (p. ej., amazon.com) y quiere iniciar una transacción con tarjeta de crédito:

• ✔️ Caso 1 – El usuario ya tiene una passkey de su issuer / banco: El merchant muestra un iframe donde puede ocurrir la autenticación con la passkey. El IFRAME es mostrado por el proceso subyacente de 3-D Secure 2 (3DSS/EMV 3DS) que ya está en vigor para las transacciones con tarjeta de crédito que necesitan soportar SCA y vinculación dinámica.

• ❌ Caso 2 – El usuario no tiene una passkey de su issuer / banco: De nuevo, el merchant muestra el iframe. Como aún no hay passkeys disponibles, el usuario se autentica con los factores de autenticación existentes (p. ej., OTP por SMS o la aplicación nativa de banca en su smartphone). En este punto, después de una autenticación exitosa, sería el momento ideal para registrar una passkey para el usuario, pero esto no está permitido debido a las restricciones del estándar WebAuthn. El registro de passkeys en un iframe de origen cruzado no está permitido (el dominio de la página principal y el del iframe tendrían que ser idénticos). Una inscripción gradual como en la siguiente captura de pantalla sería imposible:

¿Se admitirá en el futuro el registro de passkeys en iframes de origen cruzado?

Aunque las passkeys ofrecen una buena solución para la vinculación dinámica en un contexto de pago de primera parte dentro de un único dominio, en contextos de pago de tercera parte, actualmente no son compatibles con WebAuthn Nivel 2. Sin embargo, la buena noticia es que el soporte para iframes de origen cruzado ya está incorporado en la especificación en curso de WebAuthn Nivel 3 (que estará disponible de forma general a finales de 2024). Sin embargo, los navegadores todavía tienen que ponerse al día con la especificación:

A día de hoy, parece que para 2024, la cobertura para el registro de passkeys de origen cruzado podría convertirse en una realidad en los principales navegadores, lo que levantaría la limitación técnica más significativa en el uso de passkeys para pagos.

Ha habido varios intentos (p. ej., BasicCard, PaymentHandler o PaymentManifest) por parte de grupos de trabajo iniciados por Google en el W3C para mejorar la experiencia de pago en la web. Hasta ahora, ninguno ha ganado una cobertura y uso significativos en el mercado. La fricción en el proceso de pago para transacciones de ecommerce sigue siendo un gran desafío con una regulación creciente contra el fraude. El estándar de Confirmación de Pago Segura (SPC), iniciado por Google y Stripe, es actualmente el estándar más prometedor que se basa en el estándar WebAuthn.

La Confirmación de Pago Segura (SPC) aborda todos los elementos importantes de la SCA de la PSD2, incluido el requisito de vinculación dinámica, y al mismo timepo intenta mejorar la experiencia de usuario (UX).

• Ofrecer una UX nativa del navegador: SPC aprovecha el navegador para proporcionar una experiencia de autenticación consistente y optimizada en diferentes sitios de merchants y relying parties. Este enfoque tiene como objetivo mejorar la seguridad de las transacciones más allá de lo que se logra típicamente con contenido renderizado en un iframe, al tener una apariencia consistente y garantizar la conciencia del pagador:

Ejemplo de https://www.w3.org/press-releases/2023/spc-cr/

• Proporcionar evidencia criptográfica: El estándar asegura que se genere una prueba criptográfica de la confirmación del usuario de los detalles del pago y se incluya en la aserción de WebAuthn sin necesidad de codificar la información en el desafío de WebAuthn.

• Permitir el registro de terceros: A diferencia del estándar WebAuthn Nivel 2, donde el registro de un autenticador debe ocurrir en un contexto de primera parte, SPC permite el registro de passkeys directamente desde un iframe de origen cruzado. Esta capacidad aborda casos de uso comunes en el ecosistema de pagos y facilita una integración más sencilla para merchants y procesadores de pago. Como hemos discutido anteriormente, esta funcionalidad ya es parte de la próxima versión del estándar subyacente y, por lo tanto, probablemente se eliminará de SPC en el futuro.

• Autenticación de pagos de origen cruzado: SPC amplía la utilidad de WebAuthn al permitir que cualquier origen genere una aserción para una transacción, incluso si aprovecha las credenciales de otra Relying Party (sin necesidad de abandonar la página). En este caso, ni siquiera se necesita un iframe del merchant / issuer. Esta característica es particularmente útil en escenarios donde múltiples partes (merchant + issuer / banco) están involucradas en el proceso de autenticación y la aserción puede ser transportada a la Relying Party original (el proveedor de la cuenta, p. ej., un banco) para su verificación.

El ejemplo anterior está tomado del Explicador de SPC y muestra el concepto de autenticación de pagos de origen cruzado. En un proceso de pago usando SPC, el usuario permanece en el sitio del merchant (resaltado en azul) durante toda la transacción. El navegador web (coloreado en verde) mantiene la visualización del origen del merchant y también presenta un diálogo predefinido y no personalizable con toda la información importante para la vinculación dinámica (importe + beneficiario) para confirmar la transacción. Después de la confirmación del usuario, el sistema operativo (representado en naranja) maneja la autenticación biométrica necesaria para verificar la transacción.

Estos objetivos ilustran el compromiso de SPC para mejorar tanto la seguridad como la experiencia del usuario en los pagos en línea, con el objetivo de simplificar los procesos de autenticación mientras se mantienen altos estándares de seguridad en todo el panorama de pagos digitales.

Repasemos todos los flujos posibles que SPC permitiría y comparémoslos con las passkeys estándar, para que entendamos los beneficios.

Como podemos ver aquí, la distinción más importante es el registro en el sitio web del merchant dentro de un iframe, que aún no es compatible con las passkeys (ver nuestra discusión anterior) y la posibilidad completamente nueva de la autenticación de origen cruzado. Repasémoslos uno por uno.

Aquí hay un ejemplo de maqueta de registro de una passkey SPC directamente en la página de Mastercard. Como puedes ver, la creación de la passkey se ofrece justo después de completar la autenticación mediante OTP por SMS en este caso.

En este caso, la comunicación se parecería a un proceso de registro de passkeys estándar, ya que esto ocurre completamente en el contexto de primera parte.

Tomado de https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

Esta passkey SPC podría ahora usarse en el sitio de un merchant para autenticación, en un iframe en el sitio del merchant y para la autenticación de origen cruzado (ver más abajo).

Como hemos discutido antes, el proceso de registrar una passkey SPC en el sitio web de un merchant ocurriría típicamente durante la transacción de pago, dentro del contexto del flujo de 3-D Secure (3DS). Este flujo está diseñado para mejorar la seguridad de las transacciones con tarjeta de crédito y débito en línea al involucrar un paso de autenticación adicional que verifica la identidad del titular de la tarjeta.

Durante una transacción de pago, cuando se inicia el flujo 3DS, el proceso de autenticación se facilita a través de un iframe alojado en el sitio del merchant (p. ej., amazon.com) pero controlado por el proveedor de servicios de pago o el banco emisor (p. ej., mastercard.com). Este iframe sirve como un entorno seguro para que el cliente autentique su identidad utilizando los factores de autenticación existentes.

Una vez que el cliente se autentica con éxito utilizando estos factores convencionales (p. ej., OTP por SMS o la aplicación bancaria), existe la oportunidad de registrar una passkey SPC para futuras transacciones. Como el estándar SPC permite la creación de passkeys de origen cruzado desde iframes, esto funcionaría. El registro de esta passkey en el iframe implicaría típicamente que el cliente realice una acción que genere y vincule la passkey a su tarjeta de crédito, como verificar su huella dactilar o reconocimiento facial en un dispositivo compatible. Ten en cuenta que el iframe es controlado por el proveedor de servicios de pago (p. ej., PayPal) o el banco emisor (p. ej., mastercard.com). Por lo tanto, la passkey SPC se crea directamente con el issuer / banco y no con el merchant. El flujo simplificado se vería así:

Tomado de https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

En https://spc-merchant.glitch.me/, Google ha configurado una aplicación de demostración a la que se puede acceder a través de Chrome en Windows y Mac, que ilustra cómo funcionaría esto desde un iframe:

También permite jugar con el sitio del banco directamente, que está alojado en: https://spc-rp.glitch.me/reauth. En este ejemplo, no se necesita comunicación fuera de banda con APIs entre el merchant y el issuer / banco; todo es manejado por el navegador. La autenticación usando una passkey existente funcionaría de la misma manera desde el iframe.

En el siguiente ejemplo, vemos la autenticación de origen cruzado donde el usuario ya ha registrado una passkey SPC con Mastercard. El sitio del merchant de ejemplo (decorshop.com) puede activar la autenticación de origen cruzado. La diferencia principal e importante es que la página del merchant / issuer nunca es visible durante el proceso de autenticación. El navegador, en combinación con el sistema operativo, presenta la UX de pago predefinida (proporcionada por la implementación del navegador del estándar SPC) y el modal de autenticación (estándar WebAuthn). La comunicación entre el merchant y el issuer / banco se maneja en segundo plano.

Originalmente de (parcialmente ajustado): https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (Mastercard)

Originalmente de (parcialmente ajustado): https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams

Al usar la autenticación de origen cruzado, el merchant se comunica con el issuer / banco a través de alguna forma de API para intercambiar información sobre las credenciales existentes (n.º 2 en el diagrama de secuencia anterior). Si existen credenciales y el navegador del usuario admite SPC, comienza la autenticación. Al final, la aserción se devuelve hasta el issuer / banco a través de protocolos existentes como EMV 3DS, donde la aserción puede ser finalmente verificada criptográficamente (n.º 16).

Como la aserción también incluye información sobre la información mostrada por el navegador, se cumplen todos los requisitos para la vinculación dinámica. Esto sería un paso importante en términos de mejoras en la UX y la experiencia de pago del cliente.

El estándar de Confirmación de Pago Segura (SPC) es un desarrollo interesante en el mundo de la autenticación de pagos en línea, destinado a mejorar la seguridad mientras se optimiza la experiencia del usuario. A día de hoy, Google Chrome es el único navegador principal que admite SPC de alguna forma. Sin embargo, esto no es sorprendente, ya que el estándar ha sido parcialmente iniciado por Google. Por parte de otros navegadores importantes como Safari de Apple y Firefox de Mozilla, hay una notable falta de compromiso sin señales claras sobre sus planes para admitir SPC. Específicamente, Apple impulsa su propio estándar propietario Apple Pay y no parece estar interesado en otros estándares de pago.

La conexión de SPC con WebAuthn ha dificultado el proceso de desarrollo. Esto se debe a que cualquier mejora o modificación en el estándar SPC debe evaluarse cuidadosamente para evitar la redundancia y garantizar que proporcionen mejoras genuinas sobre las capacidades existentes. El objetivo es refinar SPC para satisfacer necesidades específicas dentro del proceso de pago que no están completamente cubiertas por WebAuthn, como la integración directa en el flujo de pago y proporcionar una experiencia de autenticación más amigable para el usuario que pueda operar sin problemas en diferentes sitios de merchants.

A medida que SPC continúa evolucionando, su adopción en diferentes navegadores será crucial para una implementación generalizada. La participación de actores importantes como Google indica una dirección positiva, pero será necesario un apoyo más amplio para establecer SPC como un estándar en la industria de pagos en línea.

Los desafíos descritos anteriormente, especialmente en torno a la conciencia del pagador, han impulsado el trabajo en curso en el Grupo de Trabajo de WebAuthn sobre una llamada extensión de confirmación (anteriormente conocida como “txAuthSimple”) dentro del estándar WebAuthn. Su objetivo es permitir que el autenticador o el navegador/SO (en una interfaz de usuario privilegiada) muestren los detalles de la transacción al usuario y garanticen que la relying party reciba una prueba criptográfica de que el usuario realmente confirmó estos detalles. Esto aborda directamente el problema de la “falta de garantía de la conciencia del usuario” descrito en la sección 3.3.1.

De manera similar a cómo la Confirmación de Pago Segura (SPC) proporciona un diálogo dedicado impulsado por el navegador, la extensión de confirmación aborda la preocupación de “Lo que ves es lo que firmas” (WYSIWYS, por sus siglas en inglés). Sus principales objetivos son:

• Visualización fiable de los detalles de la transacción: En lugar de dejar que el contenido web muestre el importe y el beneficiario, la extensión aprovecha la pantalla segura de un dispositivo o un diálogo de la interfaz de usuario del navegador bajo el control del SO.
• Prueba criptográfica: El autenticador (o la plataforma cliente) firma un registro del texto exacto que se mostró. Al verificar esta firma, la relying party puede confirmar que al usuario se le mostraron los detalles correctos.
• Alternativa si el autenticador no admite la visualización: En los casos en que un autenticador de hardware no puede mostrar texto, el navegador puede mostrarlo e incluirlo en los [=datos del cliente=]. Esta es una garantía más débil pero permite una mayor compatibilidad.

La extensión agrega un nuevo campo a las estructuras de extensión de WebAuthn existentes. Las Relying Parties proporcionan una cadena de texto simple (con formato básico opcional) llamada confirmation:

partial dictionary AuthenticationExtensionsClientInputs {
  USVString confirmation;
};

Cuando el cliente (navegador) recibe esto, hace lo siguiente:

1. Solicita al usuario con un diálogo de confirmación especial (para que sepan que esto es más que un inicio de sesión básico).
2. Pasa la misma cadena al autenticador como datos CBOR si el autenticador admite la extensión.
3. Devuelve cualquier salida del autenticador a la Relying Party.

Si el autenticador admite la visualización de texto, debe mostrar ese texto (p. ej., en su propia pantalla o interfaz de usuario de confianza) antes de completar la verificación del usuario. Luego incluye la misma cadena en su salida firmada.

Del lado de la Relying Party, los pasos de verificación aseguran que el texto confirmation devuelto coincida con lo que se envió. Si falta la salida de la extensión del autenticador pero la política de la Relying Party permite una alternativa, la Relying Party puede confiar en el valor de confirmation de los datos del cliente, lo que indica que el navegador mostró el texto en lugar del autenticador.

Al incrustar el beneficiario y el importe en esta extensión, el usuario ve precisamente lo que está autorizando en una pantalla de confianza. La firma del usuario ahora refleja no solo un desafío hasheado, sino también el texto exacto de la transacción. Esto es particularmente valioso para el requisito de vinculación dinámica de la PSD2, ya que:

• Cualquier discrepancia o modificación de los detalles de la transacción después de la visualización invalida la firma.
• La Relying Party puede demostrar que al usuario se le dieron los detalles correctos de la transacción en el momento de la firma, cumpliendo con el requisito de “conciencia del pagador” de la PSD2 de manera mucho más robusta que simplemente hashear datos en el desafío.

Aunque la extensión de confirmación todavía está en discusión, representa un paso crucial hacia flujos de transacciones más seguros y fáciles de usar. Al construirla directamente en la especificación de WebAuthn, ofrece:

• Interoperabilidad: Cualquier autenticador o cliente que implemente la extensión seguiría el mismo formato estandarizado.
• Flexibilidad: Las Relying Parties pueden aplicar políticas más estrictas (requiriendo visualización a nivel de autenticador) o aceptar una alternativa a nivel de navegador si es necesario.
• Alineación más amplia del ecosistema: Se alinea bien con mandatos regulatorios como la PSD2, especialmente en torno a una vinculación dinámica robusta.

Para más detalles técnicos, puedes echar un vistazo a la discusión en curso: pull request de GitHub #2020. En resumen, la extensión de confirmación también podría cerrar la última brecha importante en los flujos estándar basados en passkeys: proporcionar una prueba criptográfica de exactamente qué vio el usuario cuando dio su consentimiento, aunque de forma menos estructurada que con la Confirmación de Pago Segura. Si gana tracción entre los navegadores y los proveedores de autenticadores, podría convertirse en un método altamente estandarizado para ofrecer la garantía de seguridad WYSIWYS necesaria bajo la vinculación dinámica de la PSD2, y más allá.

Aunque SPC y la extensión de confirmación comparten el objetivo común de fortalecer la vinculación dinámica en WebAuthn, difieren en alcance y enfoque. La siguiente tabla destaca algunas de estas diferencias:

En esencia, SPC intenta ofrecer una solución de pago integral* y también incorpora la vinculación dinámica* como parte de su flujo. La extensión de confirmación*, mientras tanto, aborda el requisito de “lo que ves es lo que firmas” dentro de los mensajes estándar de WebAuthn sin imponer un flujo de pago completo. Cualquiera de los dos enfoques podría facilitar el cumplimiento de la PSD2, pero cada uno depende del soporte del navegador y del autenticador para ofrecer beneficios en el mundo real.

Nuestra recomendación para issuers, bancos e instituciones financieras es, por lo tanto, evaluar cuidadosamente qué casos de uso deben cubrirse y monitorear el desarrollo del ecosistema, ya que la facilidad de las passkeys ejercerá una presión sustancial sobre las soluciones existentes de SCA y vinculación dinámica para mejorar su UX. Los clientes exigirán soluciones biométricas en la web. Por el momento, nuestra recomendación operativa es:

• ✔️ Passkeys para pagos iniciados en el sitio web del issuer / banco: Las passkeys son una muy buena solución para que los issuers / bancos implementen la vinculación dinámica directamente en sus sitios web y aplicaciones. Podrían combinarse con otras opciones de autenticación como notificaciones push, OTP por correo electrónico / SMS o TOTP para mejorar aún más la seguridad en pagos de alto riesgo. Por supuesto, las consideraciones sobre el cumplimiento de la SCA siempre deben ser parte de esta discusión (ver también nuestra serie de 4 partes sobre passkeys y SCA).

  Una solución propuesta puede ser implementada por los propios issuers / bancos, ya que las passkeys se basan en el estándar abierto WebAuthn. Sin embargo, esto requiere un conocimiento sustancial, el manejo de casos límite y mantenerse continuamente al día con todas las nuevas regulaciones y desarrollos técnicos. La alternativa es utilizar un proveedor de autenticación de terceros. Por ejemplo, Corbado Connect admite la vinculación dinámica a través de la firma de transacciones, aprovechando desafíos de WebAuthn ajustados. Toda la información se registra en el registro de auditoría. Esto no solo es útil para las instituciones financieras, sino que puede aprovecharse para todo tipo de firmas (p. ej., firma de documentos, acciones de usuario de alto riesgo). Opcionalmente, se puede usar un OTP adicional por SMS o correo electrónico para mejorar aún más la seguridad.

• ❌ Passkeys para pagos en páginas de merchants: Desplegar passkeys para pagos en páginas de merchants aún no es posible. Los casos de uso de origen cruzado todavía están en desarrollo, pero podrían ser una opción viable a finales de 2024. Sin embargo, usar passkeys para la autenticación en páginas de merchants ya es una gran idea hoy en día y también se puede usar para comenzar a recopilar passkeys que luego también se podrán usar para pagos en el futuro.

• ❌ Passkeys SPC o extensión de confirmación para vinculación dinámica: El estándar SPC aún no ha alcanzado un estado de madurez y soporte para ser utilizado en entornos de producción.

En general, nos complace ver que los merchants y los bancos han comenzado a comprometerse con el estándar y a agregar sus requisitos y apoyo al ecosistema. De cara al futuro, las instituciones financieras y las plataformas de ecommerce deben monitorear de cerca estos avances tecnológicos y considerar cómo podrían integrar las passkeys en sus sistemas. A medida que las regulaciones continúan evolucionando, es crucial mantenerse a la vanguardia, asegurando que los procesos de autenticación de pagos se alineen con los últimos estándares de seguridad y proporcionen una experiencia de usuario segura y eficiente para los consumidores que mejore la conversión y reduzca la fricción.

¿Por qué son importantes las passkeys?

Passkeys para empresas

Las contraseñas y el phishing ponen en riesgo a las empresas. Las passkeys ofrecen la única solución MFA que equilibra seguridad y UX. Nuestro whitepaper cubre la implementación y el impacto empresarial.

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

Al revisar las passkeys para la vinculación dinámica, es evidente que, si bien las passkeys pueden ayudar a cumplir con la SCA y la vinculación dinámica, la integración técnica en servicios de terceros con el estándar WebAuthn, originalmente diseñado para contextos de primera parte, presenta algunos desafíos. Estos estándares están evolucionando gradualmente para soportar mejor los escenarios de terceros, demostrando un cambio hacia una mayor flexibilidad en su aplicación. La Confirmación de Pago Segura (SPC) busca avanzar en esta adaptación, con el objetivo de mejorar los procesos de autenticación de pagos al incorporar interacciones más amigables y fluidas en varios sitios de merchants.

Sin embargo, el avance y la aceptación más amplia del estándar SPC o de la extensión de confirmación dependen en gran medida de su adopción por parte de los principales navegadores, un proceso que ha sido lento, siendo Google Chrome actualmente el único que lo soporta. Esta lenta tasa de adopción podría impedir que especialmente SPC avance más allá de su estado actual, a menos que más navegadores comiencen a integrarlo. El desarrollo continuo y la creciente tracción de las passkeys sugieren una dirección prometedora donde los sistemas que dependen de módulos de seguridad de hardware (HSM) como Secure Enclaves, TEE y TPM también jugarán un papel importante para las aplicaciones de pago, ya que estas tecnologías ofrecen una seguridad mejorada que podría hacer que la vinculación dinámica de los pagos sea más práctica y cómoda, no solo para las transacciones iniciadas en sitios bancarios, sino también en plataformas de merchants de terceros.

El potencial de las passkeys para extender su utilidad a los procesos de pago en línea destaca un aspecto importante para asegurar las transacciones basadas en la web y hacer de Internet en general un lugar más seguro.