Biometria e a Confirmação do Pagador na Vinculação Dinâmica

A abordagem da Corbado combina passkeys (SCA) resistentes a phishing com uma tela controlada pelo banco e vinculação dinâmica do lado do servidor para atender ao Art. 5 da PSD2 RTS (“o que você vê é o que você assina”).

• Implementação principal (hoje): Exibimos o valor e o beneficiário da transação em uma UI controlada pelo Bison-Bank imediatamente antes e durante a autenticação com passkey. Nosso backend gera um desafio único que é vinculado a um registro canônico da transação (valor, beneficiário, txnId). A resposta só é aceita se corresponder a esse registro; qualquer alteração a invalida.

• Posição regulatória: A vinculação dinâmica continua sendo exigida para pagamentos remotos, mesmo com passkeys (PSD2 Art. 97(2); RTS Art. 5). A RTS não exige que o “código de autenticação” da vinculação dinâmica seja calculado no dispositivo; a geração/validação do lado do servidor é aceitável quando a integridade da exibição, a especificidade e a invalidação em caso de alteração são aplicadas (ver também EBA Q&A 2020_5366 sobre onde o código pode ser calculado).

• Segurança e auditabilidade: Vincular uma assinatura de passkey ancorada em hardware e resistente a phishing a dados específicos da transação impede adulterações e retransmissões, e produz provas fortes e irrefutáveis do consentimento do pagador. Onde houver suporte, podemos opcionalmente adotar a Confirmação de Pagamento Seguro (SPC) para adicionar prova criptográfica dos detalhes exibidos sem alterar o modelo de backend.

• SCA: Dois elementos independentes de categorias distintas (conhecimento/posse/inerência), protegidos contra divulgação/replicação com mitigações apropriadas (RTS Arts. 6–8). A independência é necessária (Art. 9), incluindo a separação quando executados em dispositivos multifuncionais (por exemplo, proteções no nível do sistema operacional, hardware seguro).
• Vinculação dinâmica (RTS Art. 5):
  • (i) o pagador é informado do valor e do beneficiário durante a autenticação
  • (ii) o código de autenticação é exclusivo para esse valor/beneficiário
  • (iii) qualquer alteração invalida o código
  • (iv) a confidencialidade/integridade do valor, do beneficiário e do código são protegidas de ponta a ponta. Isso cumpre a intenção regulatória de “o que você vê é o que você assina”.
• Implicação: Uma autenticação de usuário forte por si só não é suficiente para pagamentos. A aprovação deve ser vinculada a dados de transação específicos com evidências auditáveis da vinculação e da exibição para o pagador (RTS Art. 5(1)(a–d)).

Esclarecimento — phishing vs. autorização: As passkeys são vinculadas à origem, então domínios falsos não podem obter assinaturas válidas. No entanto, a PSD2 ainda exige vinculação dinâmica para pagamentos remotos para vincular a autorização ao valor e beneficiário exatos para invalidar qualquer alteração e para proteger a integridade do que é exibido ao pagador (RTS Art. 5(1)(a–d)). A vinculação dinâmica aborda a integridade da autorização (incluindo substituição MITM/MITB/TPP), não apenas o phishing.

A Opinião da EBA de 2019 (EBA‑Op‑2019‑06) reforça que a vinculação dinâmica vincula a autenticação ao valor e ao beneficiário, exige a independência dos fatores e aceita chaves criptográficas vinculadas ao dispositivo como posse onde existe uma vinculação única ao dispositivo. Também enfatiza a integridade do que é exibido ao pagador durante a autenticação. Opinião da EBA 2019

Antes da PSD2, muitos bancos dependiam de senhas de uso único por SMS (OTPs) ou listas de TAN impressas que muitas vezes não mostravam o valor ou o beneficiário junto com a etapa de aprovação. Essa lacuna facilitava enganar os clientes para que autorizassem transferências não intencionais, uma vez que as credenciais fossem roubadas. A vinculação dinâmica foi introduzida para fechar essa lacuna, garantindo que o pagador esteja ciente do valor e do beneficiário exatos no momento da autenticação e tornando o código de autenticação específico para esses detalhes, de modo que qualquer alteração o invalide (RTS Art. 5(1)(a–d)). Onde o SMS faz parte do fluxo, os emissores também devem garantir a confidencialidade, autenticidade e integridade do valor/beneficiário e do código em todas as fases da autenticação (Q&A 2018_4414; RTS Art. 5(2)). As aprovações em aplicativos de hoje (por exemplo, “Deseja autorizar 100 USD para João da Silva via Face ID?”) implementam esse princípio de “o que você vê é o que você assina” de uma maneira amigável para o cliente.

Hoje, no celular, dois padrões dominam. Primeiro, uma notificação push pode levar o cliente diretamente para o aplicativo para revisar os detalhes da transação e aprovar. Os supervisores esclareceram que o push pode servir como prova do elemento de posse se os controles do Artigo 7 estiverem em vigor para mitigar o uso não autorizado e impedir a replicação, e a jornada geral estiver em conformidade com a RTS; no entanto, os riscos de engenharia social permanecem e devem ser abordados na experiência do usuário (UX) (Q&A 2019_4984; RTS Art. 7).

Segundo, as aprovações usando a biometria nativa do dispositivo (com um PIN como alternativa) realizam a verificação do usuário localmente para desbloquear uma operação de chave privada. A chave privada reside em um ambiente de hardware seguro (Secure Enclave/TEE/TPM) e assina um desafio. Isso se alinha perfeitamente com a SCA: inerência (biometria) mais posse evidenciada pela vinculação ao dispositivo e uma chave criptográfica vinculada ao dispositivo (EBA‑Op‑2019‑06, paras. 25, 35–37). Para pagamentos remotos, o código deve ser dinamicamente vinculado ao valor e ao beneficiário, e esses detalhes devem ser exibidos ao pagador antes da verificação do usuário (RTS Art. 5). Se ambos os fatores estiverem em um único dispositivo, implemente ambientes de execução seguros separados e verificações de integridade para que um comprometimento de um não comprometa o outro (RTS Art. 9(2)–(3)).

Por baixo dos panos, a biometria local não se “autentica no banco” diretamente. Em vez disso, a biometria (ou o PIN alternativo) realiza a verificação do usuário no dispositivo e controla o acesso a uma chave privada não exportável armazenada em um módulo de segurança baseado em hardware. Quando o pagador aprova, o dispositivo usa essa chave privada para produzir uma assinatura digital sobre um desafio fornecido pelo banco. Se o banco derivar ou associar esse desafio a um registro canônico da transação (valor, beneficiário, identificadores), a assinatura resultante funciona como um código de autenticação específico para esses detalhes. Qualquer alteração invalidará o código porque o registro armazenado não corresponderá mais ou, em projetos aprimorados, porque a derivação do desafio muda. A parte da confirmação do pagador continua sendo um requisito de UX: mostre o valor e o beneficiário em uma visão controlada pelo banco imediatamente antes da verificação do usuário. Juntos, isso satisfaz os requisitos do Art. 5 da RTS sobre conscientização, especificidade/unicidade e invalidação em caso de alteração, enquanto os controles do Artigo 7 e a vinculação ao dispositivo evidenciam o elemento de posse.

• Posse (chaves vinculadas ao dispositivo e sincronizadas): As chaves privadas das passkeys são armazenadas em hardware seguro (TEE/Secure Enclave/TPM). As passkeys vinculadas ao dispositivo não são exportáveis, alinhando-se com as expectativas da EBA para vinculação única de dispositivo (EBA‑Op‑2019‑06, paras. 25, 35–37). As passkeys sincronizadas também podem evidenciar a posse em cada autenticação, desde que a vinculação ao dispositivo e os controles anti-replicação sejam eficazes; os reguladores enfatizaram a necessidade de um vínculo confiável entre o elemento e o dispositivo (EBA‑Op‑2019‑06; RTS Art. 7).
• Inerência/conhecimento (Verificação do Usuário): A Verificação do Usuário via biometria (inerência) ou PIN do dispositivo (conhecimento) ativa a chave localmente. Combinado com a posse, isso é uma verdadeira autenticação de dois fatores (2FA) com independência de fatores. A violação de um não compromete o outro.

A vinculação dinâmica trata de vincular a autenticação à transação. A questão para um banco é: se permitirmos que um usuário aprove um pagamento via passkey (em vez de, digamos, um OTP ou um dispositivo de assinatura), podemos garantir que essa aprovação seja específica para o valor e o beneficiário pretendidos e não possa ser reutilizada ou manipulada?

Existem 2 opções para implementar a vinculação dinâmica com passkeys:

• Vinculação do lado do servidor (padrão): Gerar um desafio WebAuthn de uso único que o backend associa ao valor e beneficiário exatos. O usuário vê “€X para Y” em uma visão controlada pelo banco e aprova com uma passkey. A resposta é aceita apenas para essa transação. Qualquer alteração a invalida.
• Inclusão criptográfica (avançada): Incorporar um hash do valor/beneficiário no desafio para que a assinatura se comprometa com os dados da transação. Isso não é exigido pela RTS, mas adiciona a garantia de que mesmo trocas no backend falhariam na verificação.

Nota explícita de conformidade: A RTS não exige que o “código de autenticação” da vinculação dinâmica seja calculado no dispositivo do pagador. Um PSP pode gerá-lo e validá-lo no servidor, desde que o valor/beneficiário sejam protegidos e qualquer alteração invalide o código (ver EBA Q&A 2020_5366 sobre a localização/momento do código). Essa é a nossa abordagem de vinculação dinâmica do lado do servidor (padrão).

Ambas produzem um “código de autenticação” único e não reutilizável, específico para a transação. A ressalva principal é a confirmação do pagador: o WebAuthn em si não prova o que foi exibido. A integridade da exibição deve vir de uma UI controlada pelo banco.

O Artigo 5 da RTS exige que o pagador veja o valor e o beneficiário durante a autenticação. O WebAuthn não atesta o que foi mostrado. Em teoria, se o aplicativo ou o sistema operacional estiver comprometido, um usuário poderia ser enganado enquanto o autenticador ainda assina. Analisaremos abaixo em detalhes como esse risco se manifesta na realidade e por que não é um risco de segurança real, mas mais uma questão de interpretação da regulamentação.

Controles de integridade de exibição que aplicamos:

• A visão controlada pelo banco renderiza valor + beneficiário: bloqueamos a invocação da passkey se a visão estiver obscurecida ou fora de foco
• Detecção de sobreposição/adulteração no aplicativo/web: sem prompts de passkey de iframes ocultos
• Controle de integridade/atestado do dispositivo: negar ou escalar em sinais de dispositivo com root/jailbreak/comprometido
• Aprovação atômica contra um registro do valor/beneficiário mantido no servidor: um novo desafio é necessário em qualquer alteração de parâmetro

Sobre a inclusão criptográfica: As extensões de “exibição de transação” do WebAuthn (SPC) não são amplamente suportadas hoje. Nossa base portátil é a vinculação do lado do servidor, reforçada pela derivação do desafio a partir do registro da transação (por exemplo, H(valor ‖ beneficiário ‖ txnId ‖ nonce)) para que a assinatura se comprometa com esses valores.

Ambos os padrões usam criptografia de chave pública com chaves de dispositivo não exportáveis, e ambos dependem da verificação local do usuário para desbloquear a operação de assinatura. Em ambos, o banco garante a confirmação do pagador mostrando o valor e o beneficiário em uma visão controlada pelo banco imediatamente antes da verificação do usuário, e garante a especificidade vinculando o código de autenticação a esses detalhes — invalidando-o em qualquer alteração (RTS Art. 5(1)(a–d)). A RTS é tecnologicamente neutra e não exige que o valor/beneficiário seja renderizado dentro de um modal biométrico do sistema operacional; ela exige a exibição ao pagador e a vinculação do código (RTS Art. 5). Quando ambos os elementos de SCA são executados em um único dispositivo, os requisitos de integridade e separação do Artigo 9 se aplicam igualmente (RTS Art. 9(2)–(3)). Finalmente, a localização do cálculo da vinculação dinâmica é flexível: pode ser realizada do lado do servidor se a integridade for preservada e qualquer alteração invalidar o código (Q&A 2020_5366). Estas são as mesmas condições sob as quais os reguladores já aceitam a biometria local com PKI — portanto, as passkeys, implementadas com os mesmos controles de confirmação do pagador e vinculação, devem ser aceitas em uma base equivalente.

Então, as passkeys simples de acordo com o padrão WebAuthn cumprem a intenção da vinculação dinâmica? Parcialmente:

• Ataques MITM/rede: Sim. A vinculação à origem e as assinaturas por desafio impedem adulteração e repetição.
• Integridade da transação: Sim. A associação no servidor ou o hashing do desafio garantem que apenas o valor/beneficiário original será verificado.
• Consentimento do pagador: Mais difícil. As passkeys não possuem uma exibição no nível do autenticador. A enganação da UI em dispositivos comprometidos pode ser possível. Algo precisa ser construído por cima para garantir o consentimento do pagador.

Por que a vinculação dinâmica ainda é necessária com passkeys

• Legal: O Art. 97(2) da PSD2 e o Art. 5 da RTS exigem a vinculação dinâmica para toda iniciação de pagamento remoto. Não há exceção para métodos resistentes a phishing.
• Segurança: As passkeys removem o phishing entre origens, mas por si só não evidenciam o que foi exibido ao pagador. A vinculação dinâmica + controles de integridade de exibição garantem que o valor/beneficiário específico que o usuário viu é o que o banco executa, e que qualquer alteração invalida a aprovação.

Em resumo, as passkeys podem satisfazer a vinculação dinâmica quando estritamente vinculadas aos dados da transação e pareadas com mecanismos de exibição confiáveis. O desafio residual é provar o que o usuário realmente viu.

A Corbado oferece uma solução compatível com a vinculação dinâmica que aborda explicitamente as considerações de consentimento do pagador acima.

// TODO: FORNECER MOCKUPS DA KARUNA E DESCREVÊ-LOS

Fluxo do processo:

• A exibição controlada pelo banco mostra ao pagador o valor e o beneficiário exatos. Nenhum prompt de passkey é mostrado a menos que esta visão esteja visível.
• Autenticação: o cliente invoca o WebAuthn com um desafio único e vinculado para a transação canonizada. O autenticador realiza a verificação do usuário (biometria ou PIN do dispositivo) e assina sobre o desafio e a origem.
• Verificação no servidor: o backend verifica o hash do RP ID e a origem, corresponde o desafio à transação armazenada, verifica UV/flags, impõe o uso único e a expiração, e compara o registro do valor/beneficiário armazenado.
• Aprovação e auditoria: somente então a transação é aprovada atomicamente. Qualquer incompatibilidade/alteração é rejeitada e requer uma nova autenticação. Um registro de auditoria imutável é persistido (ID da credencial, authenticatorData, clientDataJSON, assinatura, desafio e valor/beneficiário canonizados), opcionalmente encadeado por hash para evidência de adulteração.
• Controle de integridade do dispositivo: Avaliar os sinais de integridade e atestado do dispositivo: negar ou escalar se o dispositivo tiver root/jailbreak/comprometido.
• Canonização do beneficiário: Exibir um rótulo amigável (por exemplo, “ACME GmbH”), mas vincular e verificar contra um identificador de beneficiário canônico (por exemplo, IBAN/BIC ou outro esquema único).

Detalhes técnicos:

• Backend: criar um objeto de transação com dados canonizados (por exemplo, moeda/decimais normalizados; IBAN/beneficiário canonizados). Gerar um desafio de curta duração comprometendo-se com esses valores (por exemplo, H(valor||beneficiário||txnId||nonce)); armazenar pendente; expor apenas IDs opacos ao cliente.
• Cliente/autenticador: renderizar os detalhes do pagador em uma visão controlada pelo banco; invocar o WebAuthn (RP ID = domínio Bison) apenas quando visível; exigir verificação do usuário; o autenticador assina o desafio + origem conforme o WebAuthn.
• Verificação/finalização: validar assinatura, hash do RP ID, origem/tipo, flags de UV; anti-repetição/expiração; comparar o registro imutável de valor/beneficiário; aprovar atomicamente; persistir o registro de auditoria.
• Derivar o desafio do registro: challenge = H(valor ‖ beneficiárioCanônico ‖ txnId ‖ nonce)

Políticas de UX:

• Ênfase clara no valor/beneficiário; controles de confirmação/cancelamento acessíveis; tempos de espera curtos; novas tentativas graciosas sempre usando um novo desafio; recibos imediatos (por exemplo, “Você aprovou €X para Y”). Bloquear o prompt da passkey se a exibição estiver obscurecida e avisar se os parâmetros mudarem antes da assinatura.
• Detectar sobreposições/conteúdo obscurecido: nunca mostrar um prompt de passkey se a visão da transação não estiver visível. Rejeitar se os parâmetros mudarem no meio do fluxo e reiniciar com um novo desafio.

Nota de conformidade: Este design de ponta a ponta atende ao Art. 5 da RTS: confirmação do pagador (exibição controlada pelo banco), especificidade e unicidade (código de uso único vinculado ao valor/beneficiário), invalidação em caso de alteração (verificações rigorosas no servidor) e confidencialidade/integridade do valor/beneficiário e do código em todas as fases (RTS Art. 5(1)(a–d), 5(2); ver também Q&A 2018_4414 para integridade de SMS). A independência dos fatores (Arts. 7–9) é preservada através da posse vinculada ao dispositivo e da verificação do usuário local em dispositivos multifuncionais com proteções apropriadas (RTS Art. 9(2)–(3)).

Nota:* para fluxos web, a Corbado adotará opcionalmente a Confirmação de Pagamento Seguro (https://www.w3.org/TR/payment-request-secure-payment-confirmation/) se/quando a Apple fornecer suporte amplo, adicionando uma exibição confiável mediada pelo navegador que atesta criptograficamente o valor e o beneficiário.

Preocupação: Ataques de phishing Resposta: As passkeys são resistentes a phishing por design: elas são vinculadas à origem legítima e não envolvem segredos compartilhados, então as credenciais não podem ser coletadas em um site falso, ao contrário dos OTPs. Um invasor que faz proxy do tráfego para um domínio semelhante não consegue obter uma assinatura válida para a origem do banco. A vinculação dinâmica contribui menos nesse vetor, mas permanece obrigatória para garantir que qualquer aprovação seja única para o valor e o beneficiário pretendidos. Medidas complementares (educação sobre phishing, separação clara entre aprovações de login e de pagamento, pontuação de anomalia/risco para contextos de pagamento incomuns) reduzem ainda mais a exposição.

Preocupação: Engenharia social / Fraude de Pagamento por Push Autorizado (APP) Resposta: Nenhum autenticador pode impedir totalmente um usuário de autorizar um pagamento sob pretextos falsos (por exemplo, golpes de “conta segura”). A vinculação dinâmica garante que o usuário veja explicitamente o beneficiário e o valor e fornece fortes evidências de consentimento, mas não pode sobrepor um pagador convencido. As compensações incluem avisos contextuais (novo beneficiário, primeira transferência de grande valor), períodos de reflexão ou execução atrasada para beneficiários de alto risco, verificação mais forte do beneficiário e verificações escalonadas (confirmação extra) em sinais de risco. Notificações pós-pagamento e canais de disputa rápidos ajudam a detectar e conter os danos. Adicionamos avisos contextuais em tempo real (por exemplo, novo beneficiário, primeira transferência de grande valor), períodos de reflexão para beneficiários de alto risco, verificação mais forte do beneficiário e notificações pós-pagamento (“Você aprovou €X para Y”) para acelerar a detecção e a resposta.

Preocupação: Malware ou comprometimento do dispositivo Resposta: As chaves privadas não são exportáveis e exigem verificação local do usuário para cada assinatura, então o malware não pode simplesmente extrair credenciais. O risco realista é a enganação da UI em um sistema operacional totalmente comprometido. Mitigue com UI segura/verificada (por exemplo, confirmações protegidas), verificações de integridade do dispositivo/atestado e bloqueio de dispositivos de alto risco, e confirmações confiáveis como SPC ou uma extensão de confirmação quando disponível. Se indicadores de comprometimento aparecerem (detecção de sobreposição, root/jailbreak), use reverificação fora de banda ou negue a execução. Nenhum método de consumidor é perfeito em um dispositivo totalmente dominado, mas esses controles reduzem drasticamente a janela de oportunidade.

Preocupação: Man‑in‑the‑browser / sequestro de sessão Resposta: Extensões maliciosas ou scripts injetados podem iniciar ações na origem legítima. As passkeys vinculadas à origem impedem o phishing entre sites. A vinculação dinâmica garante que edições nos bastidores no valor/beneficiário falhem. Nós fortalecemos o canal através de controles CSP/anti-adulteração e exigindo um desafio novo e de uso único para cada confirmação.

Preocupação: Ameaça interna ou adulteração do lado do servidor Resposta: A resposta de autenticação está unicamente ligada ao valor/beneficiário original, então qualquer substituição do lado do servidor falha na validação. Mantenha registros de vinculação imutáveis e evidentes de adulteração (desafio, credencial, assinatura e valor/beneficiário canonizados) para auditoria/irrefutabilidade. Aplique a separação de deveres e controles de quatro olhos em caminhos críticos de processamento de pagamentos para reduzir o risco interno.

Preocupação: Dispositivos roubados / roubo de credenciais Resposta: A mera posse do dispositivo é insuficiente: a verificação do usuário (biometria/PIN) é necessária para cada assinatura, com limites de taxa e bloqueios no nível do sistema operacional. Cada pagamento requer um desafio novo e específico da transação; tokens de sessão genéricos não podem autorizar pagamentos arbitrários. Adições como revogação remota de dispositivos, escalonamento no uso de um novo dispositivo, verificações de geovelocidade e notificações (“Você autorizou €X para Y”) restringem ainda mais o abuso.

No geral: as passkeys reduzem materialmente os riscos de phishing e repetição; a vinculação dinâmica continua essencial para garantir a integridade da transação, vincular aprovações ao valor/beneficiário e fornecer fortes evidências de consentimento informado nos cenários de ameaça restantes.

Pergunta 1: Como podemos provar que o usuário realmente viu e concordou com o valor e o beneficiário ao usar uma passkey? Resposta: Nós aplicamos a exibição para o pagador em uma visão controlada pelo banco e vinculamos a aprovação a um registro do lado do servidor do valor/beneficiário. A asserção da passkey (authenticatorData, clientDataJSON, assinatura) é aceita apenas para o desafio derivado desse registro; qualquer alteração requer um novo desafio. Nossa auditoria evidente de adulteração vincula a asserção a “€X para o ID do Beneficiário Y” e registra que nosso sistema não prosseguiria se os detalhes fossem diferentes. Onde suportado, a SPC adiciona evidência criptográfica de que o usuário confirmou os detalhes exibidos.

Pergunta 1: Como podemos provar que o usuário realmente viu e concordou com o valor e o beneficiário ao usar uma passkey? Resposta: Esta é essencialmente a questão da irrefutabilidade. Sob a PSD2, a vinculação dinâmica foi criada para garantir que o usuário esteja ciente do que está aprovando. Com uma passkey, a evidência que retemos é a assinatura criptográfica (código de autenticação) e os dados associados (a qual valor/beneficiário ela estava vinculada em nosso servidor). Por política, exibimos os detalhes da transação ao usuário no aplicativo ou na página da web antes que ele se autentique. Registramos essa tela/visão e a subsequente autenticação bem-sucedida da passkey para essa transação específica. Em caso de disputa, podemos mostrar que o dispositivo do usuário produziu uma assinatura válida para um desafio que foi associado a (por exemplo) “€100 para a ACME Corp.” e que nosso sistema não teria prosseguido se algum detalhe fosse diferente. Nossa conformidade depende de registros seguros: garantimos que nossos sistemas sejam à prova de adulteração ao vincular a resposta da passkey aos dados da transação.

Pergunta 2: E se o dispositivo ou o sistema operacional estiver comprometido? O malware pode manipular a transação ou o processo da passkey? Resposta: O comprometimento do dispositivo é uma ameaça crítica em qualquer cenário de banco digital. Se o sistema operacional for malicioso, ele pode tentar enganar o usuário ou sequestrar processos. No entanto, mesmo neste pior cenário, as passkeys mantêm algumas proteções importantes. A chave privada não pode ser extraída por malware. O malware também não pode se passar pelo usuário para o banco, porque não pode produzir a assinatura da passkey sem a biometria/PIN do usuário. O máximo que poderia fazer é levar o usuário a autenticar algo sob pretextos falsos. A vinculação dinâmica ajuda aqui, exigindo verificações de integridade: o malware não pode alterar silenciosamente os detalhes da transação após o fato – se o fizer, a assinatura não será verificada. O ponto mais fraco é a exibição/UI: um Trojan sofisticado pode alterar o que o usuário vê (por exemplo, exibir “ACME Corp” enquanto a transação subjacente está, na verdade, indo para outro beneficiário). Isso não é trivial, especialmente se o aplicativo do banco usar frameworks de UI seguros, mas é concebível. Dito isso, se detectarmos sinais de comprometimento do dispositivo (comportamento incomum, assinaturas de malware conhecidas, etc.), recorreríamos à verificação fora de banda ou negaríamos a transação. Em resumo: Nenhuma solução é 100% se o dispositivo do usuário estiver totalmente dominado por um invasor. Passkeys + vinculação dinâmica reduzem drasticamente a superfície de ataque (um invasor não pode apenas fazer proxy de credenciais ou alterar dados de rede; ele teria que aplicar um golpe no usuário em tempo real). Se o sistema operacional for comprometido, a vinculação dinâmica pelo menos garante que qualquer incompatibilidade entre o que deveria ser e o que é aprovado seja capturada pelo nosso backend.

Pergunta 3: Se uma biometria for usada para desbloquear a passkey, isso é considerado um fator ou dois? Estamos cumprindo a regra dos 2 fatores? Resposta: Uma biometria sozinha não é suficiente para SCA – é apenas um fator de inerência. No entanto, em uma implementação de passkey, a biometria não está sozinha: a posse do dispositivo é o outro fator. A biometria do usuário desbloqueia a chave privada armazenada no dispositivo. Posse e inerência são duas categorias distintas. Isso é análogo a como muitos aplicativos de banco já satisfazem a SCA: você tem o telefone (posse) e usa sua impressão digital ou rosto para desbloquear o aplicativo (inerência). A EBA reconheceu explicitamente combinações de vinculação de dispositivo mais biometria como SCA compatível. O cenário da passkey é exatamente essa combinação. Se o usuário optar por usar um PIN em vez de biometria para desbloquear a passkey, então é posse + conhecimento, também compatível. Nós aplicamos a verificação do usuário em todas as operações de passkey (o que significa que o usuário deve fornecer biometria/PIN a cada vez), então não há situação em que apenas ter o dispositivo seja suficiente. Assim, cada autorização de pagamento via passkey é um evento de dois fatores sob as definições da PSD2.

Pergunta 4: Um invasor poderia reutilizar uma autenticação de passkey ou de alguma forma contornar a vinculação dinâmica manipulando dados em trânsito? Resposta: Não. É aqui que as passkeys e a vinculação dinâmica trabalham juntas de forma robusta. Cada autenticação WebAuthn produz uma assinatura única que está vinculada ao desafio (que geramos por transação) e está no escopo do nosso domínio. Um invasor não pode repetir essa assinatura para uma transação diferente. A própria assinatura incorpora o nonce do desafio e é válida apenas para o que foi originalmente emitida. Se um invasor interceptasse a comunicação de rede, não poderia alterar o valor ou o beneficiário sem invalidar a assinatura (já que o desafio ou o contexto da transação não corresponderiam mais). Esta é efetivamente a proteção MITM que discutimos. Além disso, as assinaturas de passkey incluem dados de origem – elas não serão verificadas se não forem enviadas para a nossa origem exata de site/aplicativo, então phishing ou redirecionamento não funcionarão. Em suma, qualquer tentativa de manipulação invalida o código de autenticação, de acordo com as regras de vinculação dinâmica. Isso é, na verdade, mais seguro do que alguns fluxos atuais baseados em OTP, onde os usuários às vezes aprovam um código genérico e há o risco de a solicitação ter sido adulterada. Com as passkeys, vinculamos criptograficamente a autenticação do usuário à sessão/transação específica.

Pergunta 5: Existem opiniões regulatórias conhecidas sobre WebAuthn/passkeys para SCA? Temos certeza de que os reguladores aceitarão as passkeys como compatíveis? Resposta: Até o momento, a EBA não publicou explicitamente opiniões sobre WebAuthn ou o termo “passkeys” em seu Q&A ou orientação. No entanto, com base nos princípios que eles estabeleceram, as passkeys se encaixam claramente nos métodos aceitáveis. A opinião da EBA de 2019 essencialmente antecipou abordagens semelhantes ao FIDO2: para posse, eles mencionam explicitamente a “troca de chaves pública/privada” com vinculação de dispositivo adequada como evidência de posse. Uma passkey WebAuthn é exatamente isso – um par de chaves pública/privada, com a metade privada vinculada de forma segura ao dispositivo. Eles também deram um aceno para a “assinatura gerada por um dispositivo” como uma prova de posse válida. Então, embora não tenham usado o termo passkey, o método é coberto por seus exemplos. Também observamos que grandes players de pagamentos na Europa estão avançando com implementações de passkey (por exemplo, PayPal), o que indica um nível de confiança de que isso é compatível com a PSD2. Este exemplo demonstra que as passkeys estão sendo aceitas como parte de fluxos de SCA compatíveis, desde que a vinculação dinâmica e os requisitos gerais sejam atendidos.

Pergunta 6: Ainda precisamos de vinculação dinâmica se as passkeys forem resistentes a phishing? Resposta: Sim. As passkeys eliminam o phishing entre origens, mas a PSD2 ainda exige a vinculação dinâmica para a iniciação de pagamentos remotos. A vinculação dinâmica vincula o valor e o beneficiário específicos ao resultado da SCA e invalida qualquer alteração, abordando a integridade da autorização além do phishing (por exemplo, substituição MITM/MITB/TPP).

A solução da Corbado é compatível com a Vinculação Dinâmica e a PSD2. A exibição pré-autenticação para o pagador, o desafio de uso único vinculado ao valor e ao beneficiário, a verificação rigorosa no servidor e a auditoria imutável satisfazem juntos os requisitos do Art. 5 da RTS sobre a confirmação do pagador, unicidade/especificidade, invalidação em caso de alteração e integridade/confidencialidade. A independência dos fatores é preservada através da posse vinculada ao dispositivo e da verificação do usuário (biometria ou PIN), alinhando-se com a orientação da EBA.

Em relação aos métodos atuais de OTP/SMS, a Corbado oferece segurança e resultados para o usuário materialmente melhores: resistência a phishing e retransmissão, prevenção de adulteração silenciosa de parâmetros, evidências irrefutáveis mais fortes e atrito reduzido através da verificação do usuário no dispositivo. Riscos residuais (por exemplo, engenharia social, dispositivos comprometidos) são mitigados com controles concretos e são mais restritos do que com métodos legados. Para a web, a Corbado pode adotar a SPC quando o suporte da plataforma (notavelmente a Apple) for amplo, adicionando prova criptográfica da exibição sem alterar a postura de conformidade principal.

Em suma, a autorização de transação baseada em passkey da Corbado atende à letra e ao espírito da vinculação dinâmica da PSD2 e melhora a resiliência a fraudes e a auditabilidade em comparação com abordagens legadas, mantendo um caminho claro para aprimoramentos futuros (SPC) à medida que o ecossistema amadurece.

Na prática, as passkeys satisfazem a vinculação dinâmica quando fazemos três coisas: exibimos o valor e o beneficiário ao pagador antes da verificação do usuário; geramos um código de autenticação específico para esses detalhes exatos; e invalidamos o código em qualquer alteração (RTS Art. 5(1)(a–d)). Isso espelha os princípios que os reguladores já aceitam para a biometria local, com a conveniência adicional de que as passkeys são nativas do sistema operacional e funcionam em canais web e de aplicativos sem um aplicativo extra. Combinadas com a vinculação à origem, elas não apresentam solicitações falsificadas — apenas prompts legítimos do site ou aplicativo original aparecem para o usuário.