Registrar uma confirmação de pagamento seguro

Para usar a confirmação de pagamento seguro (SPC, na sigla em inglês) em uma transação, o cliente precisa: registre um autenticador. Esse processo é muito semelhante ao com a adição de uma extensão de pagamento.

Neste artigo, os bancos emissores que atuam como partes confiáveis (RPs, na sigla em inglês) podem saber como para implementar o registro SPC. A experiência do usuário é explicada em mais detalhes no visão geral da confirmação de pagamento segura.

Como funciona o registro da Confirmação de pagamento seguro?

O SPC é criado como uma extensão do padrão WebAuthn.

Desde abril de 2022, o SPC só oferece suporte a autenticações de plataforma com verificação de usuários (UVPA, na sigla em inglês) em computadores. Isso significa que o cliente precisa estar em um computador ou laptop com um autenticador incorporado, como:

  • Desbloquear recurso, incluindo o Touch ID em um dispositivo macOS
  • Windows Hello em um dispositivo Windows

Registrar o dispositivo

O registro de um dispositivo pela parte confiável (RP) precisa seguir uma processo de verificação de usuário forte o suficiente. A parte restrita precisa garantir que o cliente fez login no site usando uma autenticação forte para que o sua conta não é invadida com facilidade. Cuidado: falta de segurança neste processo também coloca o SPC em risco.

Depois que a parte restrita autenticar o cliente, o cliente poderá para registrar um dispositivo.

Fluxo de trabalho de registro típico no site da parte confiável

Detecção de recursos

Antes de pedir ao cliente para registrar o dispositivo, o responsável precisa verificar se o compatível com SPC.

const isSecurePaymentConfirmationSupported = async () => {
  if (!'PaymentRequest' in window) {
    return [false, 'Payment Request API is not supported'];
  }

  try {
    // The data below is the minimum required to create the request and
    // check if a payment can be made.
    const supportedInstruments = [
      {
        supportedMethods: "secure-payment-confirmation",
        data: {
          // RP's hostname as its ID
          rpId: 'rp.example',
          // A dummy credential ID
          credentialIds: [new Uint8Array(1)],
          // A dummy challenge
          challenge: new Uint8Array(1),
          instrument: {
            // Non-empty display name string
            displayName: ' ',
            // Transparent-black pixel.
            icon: 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNk+P+/HgAFhAJ/wlseKgAAAABJRU5ErkJggg==',
          },
          // A dummy merchant origin
          payeeOrigin: 'https://non-existent.example',
        }
      }
    ];

    const details = {
      // Dummy shopping details
      total: {label: 'Total', amount: {currency: 'USD', value: '0'}},
    };

    const request = new PaymentRequest(supportedInstruments, details);
    const canMakePayment = await request.canMakePayment();
    return [canMakePayment, canMakePayment ? '' : 'SPC is not available'];
  } catch (error) {
    console.error(error);
    return [false, error.message];
  }
};

isSecurePaymentConfirmationSupported().then(result => {
  const [isSecurePaymentConfirmationSupported, reason] = result;
  if (isSecurePaymentConfirmationSupported) {
    // Display the payment button that invokes SPC.
  } else {
    // Fallback to the legacy authentication method.
  }
});

Registrar um autenticador

Para registrar um dispositivo no SPC, siga o processo de registro do WebAuthn com as seguintes informações: requisitos:

  • O autenticador de plataforma é obrigatório: authenticatorSelection.authenticatorAttachment é platform.
  • A verificação do usuário é obrigatória: authenticatorSelection.userVerification é required.
  • Credenciais detectáveis (chaves residentes) são obrigatórias: authenticatorSelection.residentKey é required.
.

Além disso, especifique um "pagamento" com isPayment: true. Especificação esta extensão sem atender aos requisitos acima vai gerar uma exceção

Algumas outras ressalvas:

  • rp.id: o nome do host da RP. A parte eTLD+1 do O domínio precisa corresponder ao local em que está sendo registrado. Ele pode ser usado para em domínios que correspondem ao eTLD+1.
  • user.id: uma expressão binária do identificador do usuário. O mesmo identificador será retornado após a autenticação, de modo que a parte restrita um identificador consistente de usuário do titular do cartão.
  • excludeCredentials: uma matriz de credenciais que o RP pode evitar registrando o mesmo autenticador.

Para saber mais sobre o processo de registro do WebAuthn, consulte webauthn.guide.

Exemplo de código de registro:

const options = {
  challenge: new Uint8Array([21...]),
  rp: {
    id: "rp.example",
    name: "Fancy Bank",
  },
  user: {
    id: new Uint8Array([21...]),
    name: "jane.doe@example.com",
    displayName: "Jane Doe",
  },
  excludeCredentials: [{
    id: new Uint8Array([21...]),
    type: 'public-key',
    transports: ['internal'],
  }, ...],
  pubKeyCredParams: [{
    type: "public-key",
    alg: -7 // "ES256"
  }, {
    type: "public-key",
    alg: -257 // "RS256"
  }],
  authenticatorSelection: {
    userVerification: "required",
    residentKey: "required",
    authenticatorAttachment: "platform",
  },
  timeout: 360000,  // 6 minutes

  // Indicate that this is an SPC credential. This is currently required to
  // allow credential creation in an iframe, and so that the browser knows this
  // credential relates to SPC.
  extensions: {
    "payment": {
      isPayment: true,
    }
  }
};

try {
  const credential = await navigator.credentials.create({ publicKey: options });
  // Send new credential info to server for verification and registration.
} catch (e) {
  // No acceptable authenticator or user refused consent. Handle appropriately.
}

Após um registro bem-sucedido, a parte restrita recebe uma credencial para enviar ao servidor para verificação.

Verificar registro

No servidor, a parte restrita precisa verificar a credencial e manter a chave pública do para uso posterior. O processo de registro do lado do servidor é igual ao registro comum do WebAuthn. Nada adicional é necessário para cumprir o SPC.

Registro a partir de um iframe

Se o pagador não tiver registrado o dispositivo com o RP (emissor do pagamento), o pagador pode se registrar no site do comerciante. Após uma autenticação bem-sucedida durante uma compra, a parte restrita pode solicitar que o pagador registre seu dispositivo indiretamente, de dentro de um iframe.

Fluxo de trabalho do registro no site de um comerciante durante o pagamento.

Para isso, o comerciante ou pai precisa permitir explicitamente essa ação em um iframe usando a Política de permissões. O emissor segue as mesmas etapas para registrar um autenticador em um iframe.

Há duas formas de o comerciante permitir o registro:

  1. A tag de iframe no HTML veiculado do domínio do comerciante adiciona um atributo allow:

    <iframe name="iframe" allow="payment https://spc-rp.glitch.me"></iframe>
    

    Verifique se o atributo allow contém payment e a origem da RP que invoca o registro do WebAuthn.

  2. O documento do frame pai (veiculado do domínio do comerciante) é enviado com um cabeçalho HTTP Permissions-Policy:

    Permissions-Policy: payment=(self "https://spc-rp.glitch.me")
    

Próximas etapas

Depois que um dispositivo é registrado para a parte confiável, o cliente pode confirmar pagamentos no site do comerciante usando a Confirmação de pagamento segura.