---
url: 'https://www.corbado.com/es/blog/vinculacion-dinamica-passkeys-spc'
title: 'Vinculación dinámica con passkeys: Confirmación de Pago Segura (SPC)'
description: 'Exploramos cómo la vinculación dinámica, las passkeys y la Confirmación de Pago Segura (SPC) se unen para potenciar los pagos digitales y cumplir con la PSD2. Descubre el papel de las passkeys en la seguridad de las transacciones.'
lang: 'es'
author: 'Vincent Delitz'
date: '2025-07-15T13:23:18.604Z'
lastModified: '2026-03-25T10:03:20.499Z'
keywords: 'vinculación dinámica, confirmación de pago segura, spc, psd2'
category: 'Passkeys Strategy'
---
# Vinculación dinámica con passkeys: Confirmación de Pago Segura (SPC)
## 1. Introducción
En nuestra completa serie de cuatro partes (parte 1, parte 2, parte 3 y parte 4) sobre la
[PSD2](https://www.corbado.com/blog/psd2-passkeys), exploramos cómo las passkeys se integran con las medidas de
**Autenticación Reforzada de Cliente (SCA)** introducidas por la
[PSD2](https://www.corbado.com/blog/psd2-passkeys). Nos centramos específicamente en los elementos de
[autenticación](https://www.corbado.com/es/glossary/jwks) requeridos por la [SCA](https://www.corbado.com/es/blog/psd2-passkeys) para
acceder a aplicaciones bancarias. Los requisitos de la [SCA](https://www.corbado.com/es/blog/psd2-passkeys) no
solo se aplican al acceso a aplicaciones, sino también a la iniciación y firma de
transacciones de [pago](https://www.corbado.com/passkeys-for-payment) 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.
## 2. ¿Qué es la vinculación dinámica en la PSD2?
La **vinculación dinámica** es un requisito de
[seguridad](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) bajo la directiva
[PSD2](https://www.corbado.com/blog/psd2-passkeys) 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](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) de los
[pagos](https://www.corbado.com/passkeys-for-payment) 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](https://www.corbado.com/es/glossary/jwks). 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](https://www.corbado.com/passkeys-for-payment)
electrónicos incluyen transferencias bancarias en software de
[banca](https://www.corbado.com/passkeys-for-banking) online, pero también [pagos](https://www.corbado.com/passkeys-for-payment) con
tarjeta de crédito en sitios de merchants.
### 2.1 Definición e importancia en la PSD2
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](https://www.corbado.com/es/glossary/jwks) generado sea
específico para el importe y el beneficiario acordados por el pagador al iniciar la
transacción de [pago](https://www.corbado.com/passkeys-for-payment) electrónico" (Artículo 97(2) de la PSD2).
Esto significa que cualquier cambio en los detalles del [pago](https://www.corbado.com/passkeys-for-payment)
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](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) 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.
### 2.2 Requisitos para la vinculación dinámica en transacciones financieras
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.
## 3. ¿Cómo se pueden usar las passkeys para la vinculación dinámica?
Primero, analicemos las diferentes opciones sobre cómo se pueden usar las passkeys en la
vinculación dinámica.
### 3.1 Opción 1: Uso estándar de 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.
### 3.2 Opción 2: Prueba criptográfica mejorada a través del desafío de WebAuthn
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í](https://www.w3.org/2024/Talks/Fime_W3C_6feb24.pdf)).
### 3.3 Limitaciones y desafíos de las opciones estándar de passkeys
Analicemos las limitaciones y desafíos de estas dos opciones.
#### 3.3.1 No se puede garantizar que el pagador sea consciente de los detalles
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.
#### 3.3.2 Caso de uso: Contexto de pago de primera parte vs. de tercera parte
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](https://www.corbado.com/glossary/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](https://www.corbado.com/passkeys-for-banking) 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](https://www.corbado.com/es/blog/mastercard-passkeys) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/merchant) muestra un [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) donde
puede ocurrir la autenticación con la passkey. El
[IFRAME](https://www.corbado.com/blog/iframe-passkeys-webauthn) es mostrado por el proceso subyacente de
[3-D Secure](https://www.corbado.com/glossary/3d-secure) 2
(3DSS/[EMV 3DS](https://www.corbado.com/es/blog/servidor-control-acceso-emv-3ds-passkeys-fido-spc)) que ya está
en vigor para las transacciones con tarjeta de crédito que necesitan soportar
[SCA](https://www.corbado.com/es/blog/psd2-passkeys) y vinculación dinámica.
- ❌ **Caso 2 – El usuario no tiene una passkey de su issuer / banco:** De nuevo, el
[merchant](https://www.corbado.com/glossary/merchant) muestra el [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn). 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](https://www.corbado.com/es/blog/passkeys-aplicaciones-nativas-webview) de
[banca](https://www.corbado.com/passkeys-for-banking) 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](https://www.corbado.com/es/blog/como-lograr-alta-adopcion-passkeys-flujos-creacion) en
un iframe de [origen cruzado](https://www.corbado.com/es/blog/passkeys-e-iframes-webauthn) 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](https://www.corbado.com/es/blog/passkeys-e-iframes-webauthn)
ya está incorporado en la especificación en curso de
[WebAuthn Nivel 3](https://www.corbado.com/es/blog/passkeys-prf-webauthn) (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:
| **Navegador/Estándar** | **Contexto de primera parte** | **Contexto de tercera parte** |
| ---------------------------------------------------------------------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| **Registrar passkeys** **en iframes de origen cruzado:** | | |
| Requerido en WebAuthn Nivel 2 | ✔️ [Detalles](https://issues.chromium.org/issues/40258856) | ❌ |
| Requerido en WebAuthn Nivel 3 | ✔️ [Detalles](https://issues.chromium.org/issues/40258856) | ✔️ [Detalles](https://issues.chromium.org/issues/40258856) |
| Implementado en Chrome | ✔️ [Detalles](https://issues.chromium.org/issues/40258856) | ✔️ [Detalles](https://issues.chromium.org/issues/40258856) |
| Implementado en Firefox | ✔️ [Detalles](https://issues.chromium.org/issues/40258856) | [Señal positiva](https://github.com/mozilla/standards-positions/issues/964) para la implementación |
| Implementado en [Safari](https://github.com/WebKit/standards-positions/issues/304) | ✔️ [Detalles](https://issues.chromium.org/issues/40258856) | A la espera de una señal para la implementación |
| **Autenticar usando passkeys** **en iframes de origen cruzado:** | | |
| Requerido en WebAuthn Nivel 2 | ✔️ | ✔️ |
| Requerido en WebAuthn Nivel 3 | ✔️ | ✔️ |
| Implementado en Chrome | ✔️ | ✔️ |
| Implementado en Firefox | ✔️ | ✔️ |
| Implementado en Safari | ✔️ | ✔️ |
A día de hoy, parece que para 2024, la cobertura para el
[registro de passkeys](https://www.corbado.com/es/blog/como-lograr-alta-adopcion-passkeys-flujos-creacion) 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.
## 4. Opción futura: Confirmación de Pago Segura (SPC)
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](https://www.corbado.com/passkeys-for-e-commerce) 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.
### 4.1 ¿Cuáles son los objetivos del estándar SPC?
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](https://www.corbado.com/blog/dynamic-linking-passkeys-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/](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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) permite el
[registro de passkeys](https://www.corbado.com/es/blog/como-lograr-alta-adopcion-passkeys-flujos-creacion)
directamente desde un iframe de [origen cruzado](https://www.corbado.com/es/blog/passkeys-e-iframes-webauthn).
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](https://www.corbado.com/blog/dynamic-linking-passkeys-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](https://www.corbado.com/glossary/relying-party) (sin
necesidad de abandonar la página). En este caso, ni siquiera se necesita un iframe del
merchant / [issuer](https://www.corbado.com/glossary/issuer). Esta característica es particularmente útil en
escenarios donde múltiples partes (merchant + [issuer](https://www.corbado.com/glossary/issuer) / banco) están
involucradas en el proceso de autenticación y la aserción puede ser transportada a la
[Relying Party](https://www.corbado.com/glossary/relying-party) original (el proveedor de la cuenta, p. ej., un
banco) para su [verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital).
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](https://www.corbado.com/es/blog/mastercard-passkeys) 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.
### 4.2 ¿Cómo serían los flujos de passkeys con SPC?
Repasemos todos los flujos posibles que SPC permitiría y comparémoslos con las passkeys
estándar, para que entendamos los beneficios.
| | **Passkeys SPC** | **Passkeys** |
| ---------------------------------------------------------------- | ---------------- | ------------ |
| **Autenticación/registro en el sitio web del issuer** | ✔️ | ✔️ |
| **Registro en el sitio web del merchant en un iframe** | ✔️ | ❌/✔️ |
| **Autenticación en el sitio web del merchant en un iframe** | ✔️ | ✔️ |
| **Autenticación de origen cruzado en el sitio web del merchant** | ✔️ | ❌ |
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.
#### 4.2.1 Passkeys SPC: Registrar / Autenticar directamente en el sitio web del issuer / banco
Aquí hay un ejemplo de maqueta de registro de una passkey SPC directamente en la página de
[Mastercard](https://www.corbado.com/blog/mastercard-passkeys). 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](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).
#### 4.2.2 Passkeys SPC: Registrar / Autenticar en el sitio web de un merchant durante el pago
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](https://www.corbado.com/glossary/3d-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](https://www.corbado.com/es/blog/passkeys-proveedores-pago-sdk-terceros) o el
banco emisor (p. ej., [mastercard](https://www.corbado.com/blog/mastercard-passkeys).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](https://www.corbado.com/blog/paypal-passkeys)) o el banco emisor (p. ej.,
[mastercard](https://www.corbado.com/blog/mastercard-passkeys).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](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_
En [https://spc-merchant.glitch.me/](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](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.
#### 4.2.3 Passkeys SPC: Autenticación de origen cruzado
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](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](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](https://www.corbado.com/es/blog/servidor-control-acceso-emv-3ds-passkeys-fido-spc), 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.
### 4.3 ¿Cuál es el estado del estándar de Confirmación de Pago Segura?
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.
## 5. Opción futura 2: La extensión de confirmación
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](https://github.com/w3c/webauthn/pull/2020) 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](https://www.corbado.com/glossary/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](#331-no-se-puede-garantizar-que-el-pagador-sea-consciente-de-los-detalles).
### 5.1 ¿Cuáles son los objetivos de la extensión de confirmación?
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.
### 5.2 ¿Cómo funciona la extensión de confirmación?
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`:
```webidl
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](https://www.corbado.com/glossary/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](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) del usuario. Luego incluye la
misma cadena en su salida firmada.
Del lado de la Relying Party, los pasos de
[verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) 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.
### 5.3 Por qué es importante para la vinculación dinámica
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.
### 5.4 Estado actual de la extensión de confirmación
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](https://github.com/w3c/webauthn/pull/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á.
### 5.5 Comparación: En qué se diferencian SPC y la extensión de confirmación
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:
| **Criterios de comparación** | **SPC** | **Extensión de confirmación** |
| ------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| **Flujo de pago integrado**
_(Maneja el proceso de pago completo, importes, beneficiario, UI, etc.)_ | ✔️ Incluye un diálogo de navegador estandarizado para pagos | ❌ Se centra solo en mostrar y firmar una cadena de texto |
| **Visualización fiable de la transacción**
_(Asegura que el usuario vea el beneficiario/importe correctos)_ | ✔️ El flujo basado en el navegador garantiza una UX consistente | ✔️ Visualización en el autenticador o en el navegador |
| **Manejo de alternativas**
_(Si el autenticador tiene capacidad de visualización limitada o nula)_ | ❌ No está diseñado específicamente para rutas alternativas | ✔️ La Relying Party puede aceptar la visualización a nivel de cliente si es necesario |
| **Alcance más allá de la vinculación dinámica**
_(Objetivos más amplios, p. ej., flujos de un solo clic, autenticación de origen cruzado)_ | ✔️ Diseñado para optimizar todo el proceso de pago | ❌ Estrictamente una extensión al desafío/respuesta estándar de WebAuthn |
| **Madurez y adopción actual**
_(Disponibilidad en todos los navegadores)_ | Baja adopción más allá de Chrome; cronograma incierto | En discusión en el [WG de WebAuthn](https://github.com/w3c/webauthn/pull/2020) pero prometedor |
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.
## 6. Recomendación para issuers / bancos
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](https://issues.chromium.org/issues/40258856):**
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](https://www.corbado.com/passkeys-for-e-commerce) 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.
## 7. Conclusión
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.