---
url: 'https://www.corbado.com/pt/blog/vinculacao-dinamica-passkeys-spc'
title: 'Vinculação Dinâmica com Passkeys: Confirmação Segura de Pagamento (SPC)'
description: 'Descubra como a vinculação dinâmica, as passkeys e a Confirmação Segura de Pagamento (SPC) podem aprimorar os pagamentos digitais. Aprenda a usar passkeys para vinculação dinâmica.'
lang: 'pt'
author: 'Vincent Delitz'
date: '2025-07-15T13:23:48.128Z'
lastModified: '2026-03-25T10:03:48.779Z'
keywords: 'vinculação dinâmica, confirmação segura de pagamento, spc'
category: 'Passkeys Strategy'
---
# Vinculação Dinâmica com Passkeys: Confirmação Segura de Pagamento (SPC)
## 1. Introdução
Na nossa abrangente série de quatro partes (parte 1, parte 2, parte 3 e parte 4) sobre a
[PSD2](https://www.corbado.com/blog/psd2-passkeys), explorámos como as passkeys se integram com as medidas de
**autenticação forte do cliente (SCA)** introduzidas pela [PSD2](https://www.corbado.com/blog/psd2-passkeys).
Focámo-nos especificamente nos elementos de [autenticação](https://www.corbado.com/pt/blog/passkeys-revolut)
exigidos pela [SCA](https://www.corbado.com/pt/blog/psd2-passkeys) para aceder a aplicações bancárias. Os
requisitos da [SCA](https://www.corbado.com/pt/blog/psd2-passkeys) não se aplicam apenas ao acesso a aplicações,
mas também ao início e assinatura de transações de [pagamento](https://www.corbado.com/passkeys-for-payment)
eletrónico à distância. Além disso, estes requisitos exigem o uso de um mecanismo
conhecido como **vinculação dinâmica**. Neste artigo, vamos explicar o que é a
[vinculação dinâmica](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador) e analisar como as passkeys
podem ser utilizadas eficazmente para implementar este mecanismo, tanto hoje como no
futuro.
## 2. O que é a Vinculação Dinâmica na PSD2?
A **vinculação dinâmica** é um requisito de segurança sob a diretiva
[PSD2](https://www.corbado.com/blog/psd2-passkeys) e o seu adendo de implementação, as Normas Técnicas
Regulamentares (RTS). O conceito foi introduzido para aumentar a segurança dos
[pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos) eletrónicos, garantindo que cada
transação está unicamente ligada a um montante específico e a um beneficiário específico
por um código de [autenticação](https://www.corbado.com/pt/blog/passkeys-revolut). Esta ligação impede qualquer
modificação dos detalhes da transação depois de esta ter sido autenticada pelo pagador,
reduzindo assim o risco de fraude. Os
[pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos) eletrónicos incluem transferências
bancárias em software de [banca](https://www.corbado.com/passkeys-for-banking) online, mas também
[pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos) com cartão de crédito em sites de
comerciantes.
### 2.1 Definição e Importância na PSD2
De acordo com a Diretiva PSD2 e as RTS que a acompanham, a
[vinculação dinâmica](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador) é definida como um processo
que garante que "o código de [autenticação](https://www.corbado.com/pt/blog/passkeys-revolut) gerado é específico
para o montante e o beneficiário acordados pelo pagador ao iniciar a transação de
[pagamento](https://www.corbado.com/passkeys-for-payment) eletrónico" (Artigo 97(2) da PSD2). Isto significa que
quaisquer alterações nos detalhes do [pagamento](https://www.corbado.com/passkeys-for-payment) invalidariam o
código de autenticação, exigindo uma nova autenticação.
A [vinculação dinâmica](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador) é crucial na PSD2, pois
aborda diretamente os riscos de segurança associados a transações eletrónicas remotas, que
são particularmente vulneráveis a diferentes tipos de fraude, como ataques
man-in-the-middle.
Ao proteger a transação desta forma, a vinculação dinâmica reduz significativamente a
possibilidade de transações não autorizadas.
### 2.2 Requisitos para a Vinculação Dinâmica em Transações Financeiras
O Artigo 5 das RTS expande os requisitos para o código de autenticação na vinculação
dinâmica. Estes requisitos incluem:
- **Consciência do pagador**: O pagador é informado do montante da transação de pagamento
e do beneficiário.
- **Código de autenticação é único**: O código de autenticação gerado para cada transação
deve ser único e não pode ser reutilizado para qualquer outra transação.
- **Código de autenticação é específico**: Os códigos gerados e o código aceite devem ser
específicos para o montante da transação e a identidade do beneficiário, conforme
confirmado pelo pagador. Qualquer alteração no montante ou no beneficiário resulta na
invalidação do código de autenticação.
- **Transmissão segura**: A confidencialidade, autenticidade e integridade são mantidas
para o montante da transação e o beneficiário em todas as fases da autenticação,
incluindo a geração, transmissão e uso do código de autenticação.
Com estes requisitos técnicos da vinculação dinâmica estabelecidos, na próxima secção
veremos como as passkeys podem ajudar como nova tecnologia. Vamos explorar o seu potencial
para otimizar e proteger os processos de autenticação de pagamentos, tornando a vinculação
dinâmica não só mais robusta, mas também mais fácil de usar.
## 3. Como Podem as Passkeys Ser Usadas para a Vinculação Dinâmica?
Vamos primeiro analisar diferentes opções de como as passkeys podem ser usadas na
vinculação dinâmica.
### 3.1 Opção 1: Uso Padrão de Passkeys na Vinculação Dinâmica
Nesta abordagem, a própria passkey atua como uma asserção criptográfica que é usada
diretamente como o código de autenticação. O desafio emitido durante o processo de
transação é gerado para refletir especificamente os detalhes da transação, como o montante
e o beneficiário, e é armazenado juntamente com essa informação. Quando o utilizador
autoriza a transação usando a sua passkey, é gerada uma assinatura única e
criptograficamente segura que pode ser verificada e armazenada com a transação. Esta
resposta não só serve como um fator de autenticação robusto, mas também liga diretamente a
aprovação aos detalhes específicos da transação, cumprindo estritamente os requisitos da
PSD2 para a vinculação dinâmica.
### 3.2 Opção 2: Prova Criptográfica Melhorada através do Desafio WebAuthn
Uma integração mais avançada envolve a codificação de detalhes adicionais da transação no
próprio desafio WebAuthn (o que tecnicamente não é exigido pela PSD2/RTS). Este método
sugere a incorporação de um hash criptográfico do beneficiário e do montante, juntamente
com outros dados aleatórios, no desafio. Ao fazer isto, o processo de autenticação não só
verifica a identidade do utilizador através da passkey, mas também afirma
criptograficamente a integridade dos detalhes da transação. Esta abordagem oferece uma
camada adicional de segurança, garantindo que qualquer adulteração do montante ou dos
detalhes do beneficiário seria detetável no ponto de pagamento final. A prova
criptográfica torna-se uma parte imutável do código de autenticação, aumentando a
confiança e a segurança em ambientes de transações de alto risco (mais informações
[aqui](https://www.w3.org/2024/Talks/Fime_W3C_6feb24.pdf)).
### 3.3 Limitações e Desafios das Opções Padrão de Passkeys
Vamos analisar as limitações e os desafios destas duas opções.
#### 3.3.1 A Consciência do Pagador Não Pode Ser Assegurada
Uma das limitações do uso de passkeys no contexto da vinculação dinâmica, particularmente
para a autenticação de pagamentos, é a falta de documentação concreta ou garantia de que o
pagador foi informado com precisão sobre as informações do beneficiário.
Embora as passkeys forneçam um método seguro para a autenticação do utilizador, elas não
verificam inerentemente se todos os detalhes da transação, especialmente os relativos ao
beneficiário, foram exibidos corretamente ao pagador.
Este problema não é exclusivo das passkeys; é um desafio comum em vários sistemas de
pagamento online. Garantir que o pagador está totalmente ciente e consente com todos os
detalhes da transação antes de iniciar o pagamento é crucial para manter a confiança e a
segurança.
#### 3.3.2 Caso de Uso: Contexto de Pagamento de Primeira Parte vs. Terceira Parte
A limitação mais significativa da integração de passkeys na vinculação dinâmica surge na
distinção entre o registo de primeira parte e de terceira parte.
**O que é um Contexto de Pagamento de Primeira Parte?**
✔️ No contexto de pagamento de Primeira Parte, o utilizador está a interagir diretamente
com o emissor / banco no seu serviço de internet e domínio. As passkeys podem ser
registadas e autenticadas sem problemas. Um exemplo poderia ser um banco que regista uma
passkey no seu próprio site e a usa para autorizar o início de um pagamento a partir do
seu software de [banca](https://www.corbado.com/passkeys-for-banking) online. Aqui, as passkeys funcionam
perfeitamente. O banco pode garantir que a passkey é usada dentro do seu domínio, mantendo
o controlo sobre o ambiente de pagamento e a segurança da transação.
Consulte o nosso post de blog sobre a implementação de
[passkeys da Mastercard](https://www.corbado.com/pt/blog/mastercard-passkeys) num contexto de pagamento de
primeira parte.
**O que é um Contexto de Pagamento de Terceira Parte?**
No contexto de pagamento de Terceira Parte, o utilizador está numa página de um
comerciante no processo de checkout num domínio diferente (por exemplo, amazon.com) e quer
iniciar uma transação com cartão de crédito:
- ✔️ **Caso 1 – O utilizador já tem uma passkey do seu emissor / banco:** O comerciante
mostra um [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) onde a autenticação com a passkey
pode acontecer. O [IFRAME](https://www.corbado.com/blog/iframe-passkeys-webauthn) é mostrado pelo processo
subjacente [3-D Secure](https://www.corbado.com/glossary/3d-secure) 2 (3DSS/EMV 3DS), que já está em vigor para
transações com cartão de crédito que precisam de suportar [SCA](https://www.corbado.com/pt/blog/psd2-passkeys)
e vinculação dinâmica.
- ❌ **Caso 2 – O utilizador não tem uma passkey do seu emissor / banco:** Novamente, o
comerciante mostra o [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn). Como ainda não há
passkeys disponíveis, o utilizador é autenticado por fatores de autenticação existentes
(por exemplo, SMS OTP ou a [aplicação nativa](https://www.corbado.com/pt/blog/passkeys-aplicacoes-nativas) de
[banca](https://www.corbado.com/passkeys-for-banking) no seu smartphone). Neste ponto, após uma autenticação
bem-sucedida, seria o momento ideal para registar uma passkey para o utilizador, mas
**isto não é permitido devido a restrições do padrão WebAuthn**. O registo de passkeys
num iframe de [origem cruzada](https://www.corbado.com/pt/blog/passkeys-iframes-webauthn) não é permitido (o
domínio da página principal e do iframe teriam de ser idênticos). Uma inscrição gradual
como na captura de ecrã seguinte seria impossível:
**O registo de passkeys em iframes de origem cruzada será suportado no futuro?**
Embora as passkeys ofereçam uma boa solução para a vinculação dinâmica em contexto de
pagamento de primeira parte dentro de um único domínio, em contextos de pagamento de
terceira parte, elas não são atualmente suportadas pelo WebAuthn Level 2. No entanto, a
boa notícia é que o suporte a iframe de
[origem cruzada](https://www.corbado.com/pt/blog/passkeys-iframes-webauthn) já está incorporado na especificação
[WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) em andamento (que será disponibilizada ao
público até ao final de 2024). No entanto, os navegadores ainda têm de acompanhar a
especificação:
| **Navegador/Padrão** | **Contexto de Primeira Parte** | **Contexto de Terceira Parte** |
| ---------------------------------------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| **Registar passkeys** **em iframes de origem cruzada:** | | |
| Exigido no WebAuthn Level 2 | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | ❌ |
| Exigido no WebAuthn Level 3 | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) |
| Implementado no Chrome | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) |
| Implementado no Firefox | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | [Sinal positivo](https://github.com/mozilla/standards-positions/issues/964) para implementação |
| Implementado no [Safari](https://github.com/WebKit/standards-positions/issues/304) | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | Aguardando sinal para implementação |
| **Autenticar usando passkeys** **em iframes de origem cruzada:** | | |
| Exigido no WebAuthn Level 2 | ✔️ | ✔️ |
| Exigido no WebAuthn Level 3 | ✔️ | ✔️ |
| Implementado no Chrome | ✔️ | ✔️ |
| Implementado no Firefox | ✔️ | ✔️ |
| Implementado no Safari | ✔️ | ✔️ |
Atualmente, parece que até 2024, a cobertura para o registo de passkeys de
[origem cruzada](https://www.corbado.com/pt/blog/passkeys-iframes-webauthn) poderá tornar-se uma realidade nos
principais navegadores, o que levantaria a limitação técnica mais significativa no uso de
[passkeys para pagamentos](https://www.corbado.com/pt/blog/passkeys-da-visa).
## 4. Opção Futura: Confirmação Segura de Pagamento (SPC)
Houve várias tentativas (por exemplo, BasicCard, PaymentHandler ou PaymentManifest) por
parte de grupos de trabalho iniciados pela Google no W3C para melhorar a experiência de
pagamento na web. Até agora, nenhuma ganhou cobertura de mercado e uso significativos. O
atrito no processo de pagamento para transações de
[comércio eletrónico](https://www.corbado.com/passkeys-for-e-commerce) continua a ser um grande desafio com o
aumento da regulamentação contra a fraude. O padrão **Secure Payment Confirmation**
(Confirmação Segura de Pagamento), que foi iniciado pela Google & Stripe, é atualmente o
padrão mais promissor, construído sobre o padrão WebAuthn.
### 4.1 Quais são os Objetivos do Padrão SPC?
A Confirmação Segura de Pagamento (SPC) aborda todos os elementos importantes da SCA da
PSD2, incluindo o requisito de vinculação dinâmica, e ao mesmo tempo tenta melhorar a
experiência do utilizador (UX).
- **Oferecer UX Nativa do Navegador**: A [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
aproveita o navegador para fornecer uma experiência de autenticação consistente e
otimizada em diferentes sites de comerciantes e partes confiáveis. Esta abordagem
destina-se a aumentar a segurança da transação para além do que é tipicamente alcançado
com conteúdo renderizado num iframe, tendo uma aparência consistente e garantindo a
consciência do pagador:
_Exemplo
de
[https://www.w3.org/press-releases/2023/spc-cr/](https://www.w3.org/press-releases/2023/spc-cr/)_
- **Fornecer Prova Criptográfica:** O padrão garante que a prova criptográfica da
confirmação dos detalhes do pagamento pelo utilizador é gerada e incluída na asserção
WebAuthn sem a necessidade de codificar a informação no desafio WebAuthn.
- **Permitir Inscrição de Terceiros:** Ao contrário do padrão WebAuthn Level 2, onde o
registo de um autenticador deve ocorrer num contexto de primeira parte, a
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) permite o registo de passkeys diretamente a
partir de um iframe de origem cruzada. Esta capacidade aborda casos de uso comuns no
ecossistema de pagamentos e facilita uma integração mais fácil para comerciantes e
processadores de pagamento. Como discutimos acima, esta funcionalidade já faz parte da
próxima versão do padrão subjacente e, portanto, provavelmente será removida da
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) no futuro.
- **Autenticação de Pagamentos de Origem Cruzada:** A SPC estende a utilidade do WebAuthn
ao permitir que qualquer origem gere uma asserção para uma transação, mesmo que utilize
credenciais de outra Parte Confiável (sem a necessidade de sair da página). Neste caso,
nem sequer é necessário um iframe do comerciante / emissor. Esta funcionalidade é
particularmente útil em cenários onde várias partes (comerciante + emissor / banco)
estão envolvidas no processo de autenticação e a asserção pode então ser transportada
para a Parte Confiável original (o fornecedor da conta, por exemplo, um banco) para
verificação.
O exemplo acima foi retirado do SPC Explainer e mostra o conceito de Autenticação de
pagamentos de Origem Cruzada: Num processo de pagamento usando SPC, o utilizador permanece
no site do comerciante (destacado a azul) durante toda a transação. O navegador web (a
verde) mantém a exibição da origem do comerciante e também apresenta um diálogo
pré-definido e não personalizável com todas as informações importantes para a vinculação
dinâmica (montante + beneficiário) para confirmar a transação. Após a confirmação do
utilizador, o sistema operativo (representado a laranja) lida com a autenticação
biométrica necessária para verificar a transação.
Estes objetivos ilustram o compromisso da SPC em melhorar tanto a segurança como a
experiência do utilizador nos pagamentos online, visando simplificar os processos de
autenticação enquanto mantém altos padrões de segurança em todo o panorama de pagamentos
digitais.
### 4.2 Como Seriam os Fluxos de Passkeys SPC?
Vamos percorrer todos os fluxos possíveis que a SPC permitiria e compará-los com as
passkeys padrão, para que possamos entender os benefícios.
| | **Passkeys SPC** | **Passkeys** |
| --------------------------------------------------------- | ---------------- | ------------ |
| **Autenticação/registo no site do emissor** | ✔️ | ✔️ |
| **Registo no site do comerciante em iframe** | ✔️ | ❌/✔️ |
| **Autenticação no site do comerciante em iframe** | ✔️ | ✔️ |
| **Autenticação de origem cruzada no site do comerciante** | ✔️ | ❌ |
Como podemos ver aqui, a distinção mais importante é o registo no site do comerciante
dentro de um iframe, que ainda não é suportado por passkeys (veja a nossa discussão
acima), e a possibilidade completamente nova de Autenticação de Origem Cruzada. Vamos
analisá-los um por um.
#### 4.2.1 Passkeys SPC: Registar / Autenticar Diretamente no Site do Emissor / Banco
Aqui está um exemplo de maquete de registo de uma passkey SPC diretamente na página da
[Mastercard](https://www.corbado.com/blog/mastercard-passkeys). Como pode ver aqui, a criação da passkey é
oferecida logo após a conclusão da autenticação via SMS OTP, neste caso.
Neste caso, a comunicação seria semelhante a um processo de registo de passkeys padrão,
pois isto acontece completamente no contexto de primeira parte.
_Retirado de
[https://developer.chrome.com/docs/payments/register-secure-payment-confirmation](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_
Esta passkey SPC poderia agora ser usada num site de comerciante para autenticação, num
iframe no site do comerciante e para Autenticação de Origem Cruzada (ver abaixo).
#### 4.2.2 Passkeys SPC: Registar / Autenticar num Site de Comerciante Durante o Pagamento
Como discutimos anteriormente, o processo de registo de uma passkey SPC num site de
comerciante ocorreria tipicamente durante a transação de pagamento, no contexto do fluxo
[3-D Secure](https://www.corbado.com/glossary/3d-secure) (3DS). Este fluxo foi concebido para aumentar a
segurança das transações online com cartão de crédito e débito, envolvendo um passo de
autenticação adicional que verifica a identidade do titular do cartão.
Durante uma transação de pagamento, quando o fluxo 3DS é iniciado, o processo de
autenticação é facilitado através de um iframe alojado no site do comerciante (por
exemplo, amazon.com), mas controlado pelo fornecedor de serviços de pagamento ou banco
emissor (por exemplo, [mastercard](https://www.corbado.com/blog/mastercard-passkeys).com). Este iframe serve como
um ambiente seguro para o cliente autenticar a sua identidade usando fatores de
autenticação existentes.
Uma vez que o cliente se autentica com sucesso usando estes fatores convencionais (por
exemplo, SMS OTP ou aplicação bancária), existe a oportunidade de registar uma passkey SPC
para transações futuras. **Como o Padrão SPC permite a criação de passkeys de origem
cruzada a partir de iframes, isto funcionaria.** O registo desta passkey no iframe
envolveria tipicamente o cliente a realizar uma ação que gera e vincula a passkey ao seu
cartão de crédito, como verificar a sua impressão digital ou reconhecimento facial num
dispositivo compatível. Tenha em mente que o iframe é controlado pelo fornecedor de
serviços de pagamento (por exemplo, [PayPal](https://www.corbado.com/blog/paypal-passkeys)) ou pelo banco emissor
(por exemplo, [mastercard](https://www.corbado.com/blog/mastercard-passkeys).com). Portanto, a passkey SPC é
criada diretamente com o emissor / banco e não com o comerciante. O fluxo simplificado
seria assim:
_Retirado
de
[https://developer.chrome.com/docs/payments/register-secure-payment-confirmation](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_
Em [https://spc-merchant.glitch.me/](https://spc-merchant.glitch.me/), a Google criou uma
aplicação de demonstração que pode ser acedida via Chrome no Windows e Mac, que ilustra
como isto funcionaria a partir de um iframe:
Também permite experimentar diretamente o site do banco, que está alojado em:
[https://spc-rp.glitch.me/reauth](https://spc-rp.glitch.me/reauth). Neste exemplo, não é
necessária comunicação fora de banda com APIs entre o comerciante e o emissor / banco –
tudo é tratado pelo navegador. A autenticação usando uma passkey existente funcionaria da
mesma forma a partir do iframe.
#### 4.2.3 Passkeys SPC: Autenticação de Origem Cruzada
No exemplo seguinte, vemos a Autenticação de Origem Cruzada onde o utilizador já registou
uma Passkey SPC com a Mastercard. O site do comerciante de exemplo (decorshop.com) pode
acionar a Autenticação de Origem Cruzada. **A diferença principal e importante é que a
página do comerciante / emissor nunca é visível durante o processo de autenticação**. O
navegador, em combinação com o sistema operativo, apresenta a UX de pagamento predefinida
(fornecida pela implementação do navegador do padrão SPC) e o modal de autenticação
(padrão WebAuthn). A comunicação entre o comerciante e o emissor / banco é tratada em
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)_
Ao usar a Autenticação de Origem Cruzada, o comerciante comunica com o emissor / banco
através de alguma forma de API para trocar informações sobre credenciais existentes (nº 2
no gráfico de sequência acima). Se existirem credenciais e o navegador do utilizador
suportar SPC, a autenticação começa. No final, a asserção é devolvida até ao emissor /
banco através de protocolos existentes como o EMV 3DS, onde a asserção pode ser finalmente
verificada criptograficamente no final (nº 16).
Como a asserção também inclui informações sobre a informação exibida pelo navegador, todos
os requisitos para a vinculação dinâmica são cumpridos. Isto seria um grande passo em
termos de melhorias na UX e na experiência de pagamento do cliente.
### 4.3 Qual é o Estado do Padrão de Confirmação Segura de Pagamento?
O padrão de Confirmação Segura de Pagamento (SPC) é um desenvolvimento interessante no
mundo da autenticação de pagamentos online, destinado a aumentar a segurança enquanto
otimiza a experiência do utilizador. Atualmente, o Google Chrome é o único navegador
principal que suporta a SPC de alguma forma. No entanto, isto não é surpreendente, pois o
padrão foi parcialmente iniciado pela Google. De outros navegadores principais como o
Safari da Apple e o Mozilla Firefox, há uma notável falta de compromisso, sem sinais
claros sobre os seus planos para suportar a SPC. Especificamente, a Apple promove o seu
próprio padrão proprietário **Apple Pay** e não parece estar interessada noutros padrões
de pagamento.
A ligação da SPC com o WebAuthn tornou o processo de desenvolvimento mais difícil. Isto
porque quaisquer melhorias ou modificações no padrão SPC precisam de ser cuidadosamente
avaliadas para evitar redundância e garantir que fornecem melhorias genuínas sobre as
capacidades existentes. O objetivo é refinar a SPC para servir necessidades específicas
dentro do processo de pagamento que não são totalmente cobertas pelo WebAuthn, como a
integração direta no fluxo de checkout e o fornecimento de uma experiência de autenticação
mais amigável ao utilizador que possa operar sem problemas em diferentes sites de
comerciantes.
À medida que a SPC continua a evoluir, a sua adoção em diferentes navegadores será crucial
para uma implementação generalizada. O envolvimento de grandes players como a Google
indica uma direção positiva, mas será necessário um apoio mais amplo para estabelecer a
SPC como um padrão em toda a indústria de pagamentos online.
## 5. Opção Futura 2: A Extensão de Confirmação
Os desafios delineados acima, especialmente em torno da **consciência do pagador**,
levaram a um trabalho contínuo no
[Grupo de Trabalho WebAuthn](https://github.com/w3c/webauthn/pull/2020) numa chamada
**extensão de confirmação** (anteriormente conhecida como “txAuthSimple”) dentro do Padrão
WebAuthN. O seu objetivo é permitir que o autenticador ou o navegador/SO (numa UI
privilegiada) exiba os detalhes da transação ao utilizador e garanta que a parte confiável
receba uma prova criptográfica de que o utilizador realmente confirmou esses detalhes.
Isto aborda diretamente o problema da “falta de garantia da consciência do utilizador”
descrito na [secção 3.3.1](#331-payer-awareness-cannot-be-assured).
### 5.1 Quais são os Objetivos da Extensão de Confirmação?
Semelhante à forma como a Confirmação Segura de Pagamento (SPC) fornece um diálogo
dedicado e orientado pelo navegador, a extensão de confirmação aborda a preocupação “O que
Vê é o que Assina” (WYSIWYS). Os seus principais objetivos são:
- **Exibição Confiável dos Detalhes da Transação**: Em vez de deixar ao conteúdo da web a
tarefa de mostrar o montante e o beneficiário, a extensão utiliza ou um ecrã seguro do
dispositivo ou um diálogo de UI do navegador sob o controlo do SO.
- **Prova Criptográfica**: O autenticador (ou plataforma cliente) assina um registo do
texto exato exibido. Ao verificar esta assinatura, a parte confiável pode confirmar que
ao utilizador foram mostrados os detalhes corretos.
- **Fallback se o Autenticador Não Suportar a Exibição**: Nos casos em que um autenticador
de hardware não pode mostrar texto, o navegador pode exibi-lo e incluí-lo nos \[=dados
do cliente=]. Esta é uma garantia mais fraca, mas permite uma compatibilidade mais
ampla.
### 5.2 Como Funciona a Extensão de Confirmação?
A extensão adiciona um novo campo às estruturas de extensão WebAuthn existentes. As Partes
Confiáveis fornecem uma string de texto simples (com formatação básica opcional) chamada
`confirmation`:
```webidl
partial dictionary AuthenticationExtensionsClientInputs {
USVString confirmation;
};
```
Quando o cliente (navegador) recebe isto, ele:
1. **Solicita** ao utilizador com um diálogo de confirmação especial (para que saibam que
isto é mais do que um login básico).
2. **Passa** a mesma string para o autenticador como dados [CBOR](https://www.corbado.com/glossary/cbor) se o
autenticador suportar a extensão.
3. **Devolve** qualquer saída do autenticador para a Parte Confiável.
Se o autenticador suportar a exibição de texto, ele **deve** mostrar esse texto (por
exemplo, no seu próprio ecrã ou UI confiável) antes de completar a verificação do
utilizador. Em seguida, inclui a mesma string na sua saída assinada.
Do lado da Parte Confiável, os passos de verificação garantem que o texto `confirmation`
devolvido **corresponde** ao que foi enviado. Se a saída da extensão do autenticador
estiver em falta, mas a política da Parte Confiável permitir um fallback, a Parte
Confiável pode confiar no valor `confirmation` dos dados do cliente — indicando que o
navegador exibiu o texto em vez do autenticador.
### 5.3 Porque é Importante para a Vinculação Dinâmica
Ao incorporar o **beneficiário** e o **montante** nesta extensão, o utilizador vê
precisamente o que está a autorizar num ecrã confiável. A assinatura do utilizador agora
reflete não apenas um desafio com hash, mas também o **texto exato da transação**. Isto é
particularmente valioso para o requisito de vinculação dinâmica da PSD2, uma vez que:
- Qualquer discrepância ou modificação dos detalhes da transação após a exibição invalida
a assinatura.
- A Parte Confiável pode provar que ao utilizador foram dados os detalhes corretos da
transação no momento da assinatura, cumprindo o requisito de “consciência do pagador” da
PSD2 de forma muito mais robusta do que apenas fazer o hash dos dados no desafio.
### 5.4 Estado Atual da Extensão de Confirmação
Embora a **extensão de confirmação** ainda esteja em discussão, ela representa um passo
crucial em direção a fluxos de transação mais seguros e fáceis de usar. Ao construí-la
diretamente na especificação WebAuthn, ela oferece:
- **Interoperabilidade**: Qualquer autenticador ou cliente que implemente a extensão
seguiria o mesmo formato padronizado.
- **Flexibilidade**: As Partes Confiáveis podem aplicar políticas mais fortes (exigindo
exibição ao nível do autenticador) ou aceitar um fallback ao nível do navegador, se
necessário.
- **Alinhamento Mais Amplo do Ecossistema**: Alinha-se bem com mandatos regulatórios como
a PSD2, especialmente em torno da vinculação dinâmica robusta.
Para mais detalhes técnicos, pode consultar a discussão em andamento:
[pull request #2020 do GitHub](https://github.com/w3c/webauthn/pull/2020). Em resumo, a
extensão de confirmação também poderia fechar a última grande lacuna nos fluxos padrão
baseados em passkeys: fornecer **prova criptográfica** de exatamente **o que** o
utilizador viu quando deu o seu consentimento, embora de forma menos estruturada do que
com a Confirmação Segura de Pagamento. Se ganhar tração entre os fornecedores de
navegadores e autenticadores, poderia tornar-se um método altamente padronizado para
fornecer a garantia de segurança WYSIWYS necessária sob a vinculação dinâmica da PSD2 — e
além.
### 5.5 Comparação: Como a SPC e a Extensão de Confirmação São Diferentes
Embora a **SPC** e a **extensão de confirmação** partilhem o objetivo comum de fortalecer
a vinculação dinâmica no WebAuthn, elas diferem em escopo e abordagem. A tabela abaixo
destaca algumas dessas diferenças:
| **Critérios de Comparação** | **SPC** | **Extensão de Confirmação** |
| ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| **Fluxo de Pagamento Integrado**
_(Lida com checkout completo, montantes, beneficiário, UI, etc.)_ | ✔️ Inclui um diálogo de navegador padronizado para pagamentos | ❌ Foca-se apenas em exibir e assinar uma string de texto |
| **Exibição de Transação Confiável**
_(Garante que o utilizador vê o beneficiário/montante correto)_ | ✔️ Fluxo baseado no navegador garante UX consistente | ✔️ Exibição no autenticador ou no navegador |
| **Gestão de Fallback**
_(Se o autenticador tiver capacidade de exibição limitada ou nenhuma)_ | ❌ Não projetado especificamente para caminhos de fallback | ✔️ A Parte Confiável pode aceitar exibição ao nível do cliente, se necessário |
| **Escopo Além da Vinculação Dinâmica**
_(Objetivos mais amplos, por exemplo, fluxos de um clique, autenticação de origem cruzada)_ | ✔️ Projetado para otimizar todo o processo de checkout | ❌ Estritamente uma extensão ao desafio/resposta padrão do WebAuthn |
| **Maturidade e Adoção Atuais**
_(Prontidão entre navegadores)_ | Baixa adoção além do Chrome; cronograma incerto | Em discussão no [WG WebAuthn](https://github.com/w3c/webauthn/pull/2020), mas promissor |
Em essência, a SPC tenta oferecer uma solução de pagamento abrangente\* e também incorpora
a vinculação dinâmica\* como parte do seu fluxo. A extensão de confirmação\*, por sua vez,
aborda o requisito _“o que vê é o que assina”_ _dentro_ das mensagens padrão do WebAuthn
sem impor um fluxo de pagamento completo. Qualquer uma das abordagens poderia facilitar a
conformidade com a PSD2, mas cada uma depende do suporte do **navegador** e do
**autenticador** para oferecer benefícios no mundo real.
## 6. Recomendação para Emissores / Bancos
A nossa recomendação para emissores, bancos e instituições financeiras é, portanto,
avaliar cuidadosamente quais casos de uso precisam ser cobertos e monitorizar o
desenvolvimento do ecossistema, pois a facilidade das passkeys exercerá uma pressão
substancial sobre as soluções existentes de SCA e vinculação dinâmica para melhorar a sua
UX. Os clientes exigirão soluções biométricas na web. No momento, a nossa recomendação
operacional é:
- ✔️
**[Passkeys para Pagamentos iniciados no Site do Emissor / Banco](https://issues.chromium.org/issues/40258856):**
As passkeys são uma solução muito boa para emissores / bancos implementarem a vinculação
dinâmica diretamente nos seus sites e aplicações. Elas poderiam ser combinadas com
outras opções de autenticação como notificações push, email / SMS OTP ou TOTP para
aumentar ainda mais a segurança para pagamentos de alto risco. Claro, as considerações
relativas à conformidade com a SCA devem sempre fazer parte desta discussão (veja também
a nossa série de 4 partes sobre passkeys e SCA).
Uma solução proposta pode ser implementada pelos próprios emissores / bancos, pois as
passkeys são baseadas no padrão aberto WebAuthn. No entanto, isto requer um
conhecimento substancial, lidar com casos de exceção e manter-se continuamente
atualizado com todas as novas regulamentações e desenvolvimentos técnicos. A
alternativa é usar um fornecedor de autenticação de terceiros. Por exemplo, o Corbado
Connect suporta vinculação dinâmica através da assinatura de transações, aproveitando
desafios WebAuthn ajustados. Todas as informações são registadas no log de auditoria.
Isto não é útil apenas para instituições financeiras, mas pode ser aproveitado para
todos os tipos de assinaturas (por exemplo, assinatura de documentos, ações de
utilizador de alto risco). Opcionalmente, um SMS ou E-Mail OTP adicional pode ser
usado para melhorar ainda mais a segurança.
- ❌ **Passkeys para Pagamentos em Páginas de Comerciantes:** Lançar passkeys para
pagamentos em páginas de comerciantes ainda não é possível. Os casos de uso de origem
cruzada ainda estão em desenvolvimento, mas podem ser uma opção viável no final de 2024.
Usar passkeys para autenticação em páginas de comerciantes, no entanto, já é uma ótima
ideia hoje e também pode ser usado para começar a coletar passkeys que poderão ser
usadas para pagamentos no futuro.
- ❌ **Passkeys SPC ou Extensão de Confirmação para Vinculação Dinâmica**: O Padrão SPC
ainda não atingiu um estado maduro e suporte para ser usado em ambientes de produção.
No geral, estamos felizes em ver que comerciantes e bancos começaram a interagir com o
padrão e a adicionar os seus requisitos e suporte ao ecossistema. Olhando para o futuro,
as instituições financeiras e as plataformas de
[comércio eletrónico](https://www.corbado.com/passkeys-for-e-commerce) devem monitorizar de perto estes avanços
tecnológicos e considerar como podem integrar as passkeys nos seus sistemas. À medida que
as regulamentações continuam a evoluir, é crucial estar à frente da curva, garantindo que
os processos de autenticação de pagamentos se alinhem com os mais recentes padrões de
segurança e proporcionem uma experiência de utilizador segura e eficiente para os
consumidores, que melhore a conversão e reduza o atrito.
## 6. Conclusão
Ao analisarmos as passkeys para a vinculação dinâmica, é evidente que, embora as passkeys
possam ajudar a cumprir a SCA e a vinculação dinâmica, a integração técnica em serviços de
terceiros com o padrão WebAuthn, originalmente concebido para contextos de primeira parte,
apresenta alguns desafios. Estes padrões estão a evoluir gradualmente para suportar melhor
cenários de terceiros, demonstrando uma mudança em direção a uma maior flexibilidade na
sua aplicação. A Confirmação Segura de Pagamento (SPC) procura aprofundar esta adaptação,
visando melhorar os processos de autenticação de pagamentos ao incorporar interações mais
amigáveis e fluidas em vários sites de comerciantes.
No entanto, o avanço e a aceitação mais ampla do padrão SPC ou da Extensão de Confirmação
dependem fortemente da sua adoção pelos principais navegadores — um processo que tem sido
lento, com o Google Chrome a ser atualmente o único apoiante. Esta lenta taxa de adoção
poderia potencialmente impedir, especialmente a SPC, de avançar para além do seu estado
atual, a menos que mais navegadores comecem a integrá-la. O desenvolvimento contínuo e a
crescente tração das passkeys sugerem uma direção promissora onde os sistemas que dependem
de módulos de segurança de hardware (HSMs), como enclaves seguros, TEEs e TPMs, também
desempenharão um papel importante para aplicações de pagamento, pois estas tecnologias
oferecem segurança aprimorada que poderia tornar a vinculação dinâmica de pagamentos mais
prática e confortável, não apenas para transações iniciadas em sites bancários, mas também
em plataformas de comerciantes de terceiros.
O potencial das passkeys para estender a sua utilidade aos processos de pagamento online
destaca um aspeto importante na segurança das transações baseadas na web e em tornar a
Internet em geral um lugar mais seguro.