Vinculação Dinâmica com Passkeys: Confirmação Segura de Pagamento (SPC)

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

Get Report

Na nossa abrangente série de quatro partes (parte 1, parte 2, parte 3 e parte 4) sobre a PSD2, explorámos como as passkeys se integram com as medidas de autenticação forte do cliente (SCA) introduzidas pela PSD2. Focámo-nos especificamente nos elementos de autenticação exigidos pela SCA para aceder a aplicações bancárias. Os requisitos da SCA não se aplicam apenas ao acesso a aplicações, mas também ao início e assinatura de transações de pagamento 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 e analisar como as passkeys podem ser utilizadas eficazmente para implementar este mecanismo, tanto hoje como no futuro.

A vinculação dinâmica é um requisito de segurança sob a diretiva PSD2 e o seu adendo de implementação, as Normas Técnicas Regulamentares (RTS). O conceito foi introduzido para aumentar a segurança dos 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. 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 eletrónicos incluem transferências bancárias em software de banca online, mas também pagamentos com cartão de crédito em sites de comerciantes.

De acordo com a Diretiva PSD2 e as RTS que a acompanham, a vinculação dinâmica é definida como um processo que garante que "o código de autenticação gerado é específico para o montante e o beneficiário acordados pelo pagador ao iniciar a transação de pagamento eletrónico" (Artigo 97(2) da PSD2). Isto significa que quaisquer alterações nos detalhes do pagamento invalidariam o código de autenticação, exigindo uma nova autenticação.

A vinculação dinâmica é 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.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

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.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

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

As empresas confiam na Corbado para proteger os seus utilizadores e tornar os logins mais simples com passkeys. Obtenha a sua consulta gratuita sobre passkeys agora.

Obtenha uma consulta gratuita

Vamos primeiro analisar diferentes opções de como as passkeys podem ser usadas 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.

Become part of our Passkeys Community for updates & support.

Join

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).

Vamos analisar as limitações e os desafios destas duas opções.

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.

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 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 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 onde a autenticação com a passkey pode acontecer. O IFRAME é mostrado pelo processo subjacente 3-D Secure 2 (3DSS/EMV 3DS), que já está em vigor para transações com cartão de crédito que precisam de suportar SCA e vinculação dinâmica.

• ❌ Caso 2 – O utilizador não tem uma passkey do seu emissor / banco: Novamente, o comerciante mostra o iframe. 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 de banca 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 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 já está incorporado na especificação WebAuthn Level 3 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:

Atualmente, parece que até 2024, a cobertura para o registo de passkeys de origem cruzada poderá tornar-se uma realidade nos principais navegadores, o que levantaria a limitação técnica mais significativa no uso de passkeys para pagamentos.

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 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.

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 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/

• 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 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 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.

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.

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.

Aqui está um exemplo de maquete de registo de uma passkey SPC diretamente na página da Mastercard. 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

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).

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 (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.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) ou pelo banco emissor (por exemplo, mastercard.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

Em 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. 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.

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 (Mastercard)

Originalmente de (parcialmente ajustado): 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.

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.

Os desafios delineados acima, especialmente em torno da consciência do pagador, levaram a um trabalho contínuo no Grupo de Trabalho WebAuthn 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.

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.

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:

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 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.

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.

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. 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.

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:

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.

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: 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 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.

Porque é que as Passkeys são importantes?

Passkeys para Empresas

As palavras-passe e o phishing colocam as empresas em risco. As passkeys oferecem a única solução MFA que equilibra segurança e UX. O nosso whitepaper aborda a implementação e o impacto nos negócios.

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

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.