EMVCO, FIDO Alliance e W3 trabalham juntos para estabelecer especificações técnicas interoperáveis para a segurança dos pagamentos online
As três entidades trabalham em conjunto para definir padrões comuns de segurança, em seus domínios de atividades. A ação comum envolve os seguintes documentos:
- EMV® 3-D Secure , EMV® Payment Tokenisation e EMV® Secure Remote Commerce.
- Protocolo Cliente para Autenticador FIDO (CTAP)
- W3C Web Authentication, Payment Request API e Payment Apps
Este POST foi produzido a partir do documento conjunto das entidades, publicado em 15 de setembro de 2020.
O escopo do esforço conjunto envolve o caso específico das compras realizadas por um consumidor num site Internet, usando um browser, onde o usuário fornece as informações. Ou seja, o escopo não contempla os casos das compras realizadas com dados do comprador em arquivo.
A ação envolve alguns desafios importantes:
- Reduzir a fraude, mas não às custas da privacidade do usuário ou dos requisitos regulatórios.
- Melhorar a experiência do usuário, mas não em detrimento da segurança e do custo.
Objetivos
Oferecer a melhor experiência do usuário
As premissas para este objetivo englobam:
- Mitigar os esforços relativos ao uso das senhas (criação, memorização, roubo de dados etc.)
- Simplificar as experiências dos usuários:
- Reduzindo o atrito dos processo de autenticação do usuário no checkout, incluindo o acesso a uma lista de cartões armazenada na nuvem ou autenticação durante uma transação;
- Reduzindo a necessidade digitação e outras atividades, relativas a fornecimento de endereço, informações de contato e credenciais de pagamento durante a finalização de uma compra;
- Reduzindo a confusão com o redirecionamento do usuário entre o site de compras e o site de pagamentos
- Criando uma experiência familiar que permita a ele minimizar a desconfiança quando vivencia experiências de checkout muito diferentes na web.
- Melhorar o gerenciamento do ciclo e vida das credenciais, sem rupturas nos casos em quedos cartões são substituídos ou comprometidos.
Aumentar a segurança, reduzir as fraudes e ampliar as taxas de aprovação
Sobre este ponto de vista, o grupo de trabalho procura:
- Evitar as invasões de conta, atividades de phishing, métodos de roubo de senhas e ataques de força bruta. A meta é reduzir o nível de dependência em relação senhas para a autenticação.
- Reduzir o comprometimento de dados das contas e ajudar a garantir a conformidade com o PCI SSC.
- Assegurar que apenas as partes autorizadas utilizem cartões de crédito
- Melhorar a capacidade de avaliação de risco dos emissores, par aumentar a taxa de conversão das transações e reduzir as fraudes.
Reduzir o esforço e o custo de integração
A meta é reduzir os custos para os comerciantes e seus provedores de serviços de pagamento, para criar uma experiência segura e eficiente de checkout. A redução sugerida vai decorrer da padronização e da interoperabilidade, pelo uso de APIs.
Proteger a privacidade do usuário
Neste aspecto, o objetivo é reduzir ao mínimo o compartilhamento dos dados usuários, garantindo que somente as partes interessadas tenham acesso eles, além de evitar o rastreamento dos usuários em sites.
Atender aos requisitos das regulamentações
As entidades visam facilitar o cumprimento de normas regulatórias de autenticação dos clientes, como a diretiva PSD2 da Europa, além de outros regulamentos adotados na Índia, Cingapura etc. e cumprir os requisitos referentes às leis de proteção de dados como GRPD, LGPD e outras.
O que as tecnologias podem aportar
Em cada entidade podem existir especificações que atendem a capacidades ou necessidades comuns. Exemplos:
- FIDO2 e 3-D Secure estão relacionados à autenticação multifator
- A API de solicitação de pagamento e o SRC envolvem a melhoria da experiência do usuário durante a finalização da compra. O SRC concentra-se em pagamentos baseados em PAN, enquanto que a API de solicitação de pagamento é mais geral, mas os pagamentos baseados em PAN podem ser parte desse escopo mais amplo. O W3C Web Payments Working Group está discutindo “como implementar SRC usando a API de solicitação de pagamento”.
Tokenização EMV
Os padrões de tokenização EMV definem um ecossistema de informações que substitui os dados do cartão em uma variedade de casos de uso, incluindo as transações que utilizam cartões em arquivo (Card on File – COF). O comércio pode assumir a função de “token requestor”, substituindo o número do cartão por um token destinado às compras em seu estabelecimento, reduzindo o risco de vazamento da base de dados e cartões.
Os controles de restrição de domínio (Token Domains Restriction Controls) reduzem as oportunidades de uso não autorizado ou uso indevido, limitando o uso de um token de pagamento a um canal específico, como e-commerce, para uma determinada transação ou para um comerciante específico. Outros métodos de controle do uso dos cartões podem ser agregados ao processo, oferecendo ainda mais segurança.
Outros benefícios da Tokenização EMV:
- Se um cartão físico for substituído ou os dados do PAN forem perdidos, roubados ou comprometidos, o comerciante de e-commerce ainda pode usar o token de pagamento armazenado, que será associado ao novo cartão emitido.
- O comerciante pode reduzir o escopo do ambiente de dados do titular do cartão no que se refere à conformidade com o PCI SSC, substituindo o PAN por Tokens de Pagamento ou usando IDs de referência de token. No caso de um provedor de serviços de pagamento, ele podem armazenar o Token de Pagamento enquanto o comerciante armazena um ID de referência do token.
EMV 3D Secure
O protocolo 3D Secure permite que o emissor do cartão avalie as informações referentes à transação para autenticar o portador utilizando métodos de análise de risco e solicitando informações adicionais, se necessário.
Numa atividade de responsabilidade compartilhada, comerciante e emissor avaliam as informações relativas à transação. Os dados compartilhados podem incluir dados de identidade FIDO. Desta forma é possível reduzir o atrito da autenticação, permitindo uma melhor experiência de compra.
EMV SRC – Secure remote Commerce
O SRC descreve uma arquitetura geral, estabelece requisitos gerais e de interface do usuário e contempla APIs e um SDK baseado em Java Script com os seguintes objetivos:
- Aumentar a consistência em todo o ambiente remoto, permitindo soluções que fornecem interoperabilidade e conveniência;
- Reduzir a complexidade do ecossistema, permitindo processos e interfaces de integração consistentes e simplificados entre as partes interessadas;
- Aumentar a segurança de sites e aplicativos de comércio remoto por e a transmissão segura de informações de pagamento e checkout;
- Fornecer compatibilidade de integração para outras especificações EMV, incluindo EMV® 3-D Secure e EMV® Tokenização;
- Reduzir a entrada manual repetitiva de PAN, permitindo a identificação consistente do consumidor, diminuindo potencialmente o abandono do carrinho de compras;
- Facilitar o reconhecimento do consumidor, por meio de um ícone de pagamento, que pode ser usado gratuitamente;
- Facilitar a inovação da indústria, fornecendo uma base para o comércio remoto em novos dispositivos, ambientes remotos e tecnologias de checkout.
Na perspectiva do usuário, ele pode registrar seus cartões no SRC. Estes cartões são associados a uma identidade para que eles possam ser utilizados no mesmo ambiente ou em diversos ambientes distintos.
Durante uma transação, a identidade do usuário pode ser verificada para acessar a lista de cartões armazenados com sistemas SRC – os usuários recebem metadados (por exemplo, os últimos 4 dígitos do PAN de financiamento, arte do cartão) para facilitar a seleção de cartões elegíveis. Após a seleção de um cartão, os usuários podem precisar se autenticar para a transação e depois disso credenciais de pagamento, como por exemplo um token associado ao cartão são recuperadas no SRC e devolvidas para a parte que iniciou a solicitação de pagamento.
FIDO 2
FIDO 2 é o resultado combinação de de duas tecnologias: Autenticação da Web (patrocinado pelo consórcio W3C) e “Client to Authenticator Protocol” – CTAP (patrocinado pelo FIDO). Em resumo, a autenticação de um dispositivo é associada ao autenticação de um usuário web, criando protocolo unificado de autenticação. Exemplos:
- Em um smartphone utilizado por uma única pessoa, os componentes de autenticação do dispositivo vão ser associados ao componente de autenticação do usuário (Face ID ou digital, por exemplo), para criar um protocolo unificado de autenticação.
- Em um tablet compartilhado, cada usuário identificado, associado ao dispositivo, criaria um protocolo específico.
Muitos smartphones e laptops vêm de fábrica com autenticadores FIDO já integrados, tornando a autenticação FIDO uma abordagem natural, de baixo atrito e escalonável para autenticação do consumidor (por exemplo, para uma lista de cartões ou para autenticar durante uma transação).
Os protocolos FIDO envolvem duas etapas:
- Registro – Os padrões FIDO são baseados na criptografia de chave pública. Durante o registro FIDO, o usuário cria um PIN, codifica ou registra dados biométricos e em seguida o autenticador gera um par de chaves públicas / privadas específica da Parte Confiante. O par de chaves não é conhecido por nenhuma outra parte. O registro envolve o envio da chave pública de forma protegida para o servidor da Parte Confiante.
- Autenticação – A autenticação, por sua vez, também é dividida em duas etapas:
- Verificação do usuário local – corresponde. uma ação do usuário junto ao dispositivo, como fazer um gesto, confirmar sua digital ou introduzir um código
- Autenticação online – o servidor de parte confiável envia uma mensagem ao autenticador que é assinada criptograficamente com a chave privada armazenada no autenticador que foi usado no registro. A resposta assinada é retornada ao servidor, onde é verificada. A autenticação online completa o segundo fator de autenticação.
API de solicitação de pagamento e aplicativos de pagamento
A API de solicitação de pagamento define um novo recurso do navegador que o torna mais fácil e rápido (do que formulários da Web) para o comerciante para solicitar o pagamento e para que os usuários concluam um check-out, retornando informações armazenadas (por exemplo, informações de contato, endereços e credenciais de pagamento).
O comerciante declara os métodos de pagamento suportados por meio da API. Quando o usuário clica em um “botão de compra”, isso faz com que o navegador determine quais aplicativos de pagamento o usuário tem (ou pode instalar na hora) para esses métodos de pagamento.
Existem três opções de aplicativos de pagamento: aplicativos móveis nativos, sites ou o próprio navegador (por exemplo, muitos navegadores armazenam informações básicas do cartão).
Se apenas um aplicativo de pagamento corresponde ao que o comerciante aceita, o navegador pode iniciá-lo automaticamente.
Se estão disponíveis vários aplicativos de pagamento, o navegador solicita que o usuário escolha um. O usuário interage com um aplicativo de pagamento para completar a transação. O navegador retorna dados do aplicativo de pagamento para o comerciante ou seu provedor de pagamentos, de acordo com quem chamou a API.
A Payment Handler API define como os aplicativos de pagamento baseados na Web registram os métodos de pagamento que eles suportam como o navegador inicia o aplicativo de pagamento e como o aplicativo de pagamento retorna dados após a conclusão da interação do usuário.
A API de solicitação de pagamento e os aplicativos de pagamento podem ser usados com uma variedade de métodos de pagamento. O seguinte diagramailustra um exemplo de jornada do usuário que essas APIs permitem, com seleção opcional de aplicativo de pagamento.
