Sichere Zahlungsbestätigung einrichten

Um in einer Transaktion die sichere Zahlungsbestätigung (Secure Payment Verification, SPC) verwenden zu können, muss der Kunde zuerst einen Authenticator registrieren. Dieser Vorgang ist dem WebAuthn-Registrierungsprozess sehr ähnlich, beinhaltet aber eine Zahlungserweiterung.

In diesem Artikel können ausstellende Banken, die als vertrauende Parteien (RPs) agieren, erfahren, wie sie die SPC-Registrierung implementieren. Die Nutzererfahrung wird in der Übersicht über die sichere Zahlungsbestätigung weiter erläutert.

Wie funktioniert die sichere Registrierung zur Zahlungsbestätigung?

SPC ist eine Erweiterung des WebAuthn-Standards.

Ab April 2022 unterstützt SPC nur noch UVPA (User Verificationing Platform Authenticators) auf Computern. Das bedeutet, dass der Kunde einen Desktop oder Laptop mit einem eingebetteten Authenticator verwenden muss, zum Beispiel:

  • Funktionen wie Touch ID auf macOS-Geräten entsperren
  • Windows Hello auf einem Windows-Gerät

Gerät registrieren

Für die Registrierung eines Geräts durch die vertrauende Partei sollte ein ausreichendes Verfahren zur Nutzerbestätigung angewendet werden. Das RP muss dafür sorgen, dass sich der Kunde mit einer starken Authentifizierung bei der Website angemeldet hat, damit das Konto nicht leicht gehackt werden kann. Seien Sie vorsichtig: Mangelnde Sicherheit bei diesem Prozess gefährdet auch SPC.

Nachdem das RP den Kunden erfolgreich authentifiziert hat, kann der Kunde jetzt ein Gerät registrieren.

Typischer Registrierungsablauf auf der Website der vertrauenden Partei

Funktionserkennung

Bevor der Kunde aufgefordert wird, das Gerät zu registrieren, muss das RP prüfen, ob der Browser SPC unterstützt.

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

Authenticator registrieren

Folgen Sie dem WebAuthn-Registrierungsprozess mit den folgenden Anforderungen, um ein Gerät für SPC zu registrieren:

  • Die Plattformauthentifizierung ist erforderlich: authenticatorSelection.authenticatorAttachment ist platform.
  • Die Nutzerbestätigung ist erforderlich: authenticatorSelection.userVerification ist required.
  • Erkennbare Anmeldedaten (Resident Schlüssel) sind erforderlich: authenticatorSelection.residentKey ist required.

Gib außerdem mit isPayment: true eine Zahlungserweiterung an. Wenn diese Erweiterung angegeben wird, ohne die oben genannten Anforderungen zu erfüllen, wird eine Ausnahme ausgelöst.

Weitere Einschränkungen:

  • rp.id: der Hostname des RP. Der eTLD+1-Teil der Domain muss mit dem Ort übereinstimmen, der registriert wird. Es kann zur Authentifizierung bei Domains verwendet werden, die mit eTLD+1 übereinstimmen.
  • user.id: ein binärer Ausdruck der Nutzerkennung. Bei erfolgreicher Authentifizierung wird dieselbe ID zurückgegeben. Daher sollte der RP eine einheitliche Nutzer-ID des Karteninhabers bereitstellen.
  • excludeCredentials: ein Array von Anmeldedaten, mit dem das RP die Registrierung desselben Authenticator vermeiden kann.

Weitere Informationen zum WebAuthn-Registrierungsprozess finden Sie unter webauthn.guide.

Beispiel für einen Registrierungscode:

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

Nach einer erfolgreichen Registrierung erhält der RP einen Berechtigungsnachweis, der zur Überprüfung an den Server gesendet wird.

Registrierung bestätigen

Auf dem Server muss der RP die Anmeldedaten überprüfen und den öffentlichen Schlüssel für die spätere Verwendung aufbewahren. Die serverseitige Registrierung ist mit einer normalen WebAuthn-Registrierung identisch. Zur Einhaltung der SPC sind keine weiteren Schritte erforderlich.

Registrierung innerhalb eines iFrames

Wenn der Zahlende sein Gerät nicht beim RP (Zahlungsaussteller) registriert hat, kann er sich auf der Händlerwebsite registrieren. Nach einer erfolgreichen Authentifizierung während eines Kaufs kann das RP den zahlenden Nutzer auffordern, sein Gerät indirekt über einen iFrame zu registrieren.

Workflow der Registrierung auf der Website eines Händlers während der Zahlung

Dazu muss der Händler oder übergeordneter Partner diese Aktion in einem iFrame mithilfe der Berechtigungsrichtlinie explizit zulassen. Der Aussteller führt dieselben Schritte aus, um einen Authenticator in einem iFrame zu registrieren.

Händler haben zwei Möglichkeiten, die Registrierung zu ermöglichen:

  1. Mit dem iFrame-Tag im HTML-Code, der von der Händlerdomain bereitgestellt wird, wird ein allow-Attribut hinzugefügt:

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

    Das Attribut allow muss payment und den RP-Ursprung enthalten, der die WebAuthn-Registrierung aufruft.

  2. Das von der Händlerdomain bereitgestellte übergeordnete Frame-Dokument wird mit einem Permissions-Policy-HTTP-Header gesendet:

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

Nächste Schritte

Sobald ein Gerät bei der vertrauenden Partei registriert wurde, kann der Kunde Zahlungen auf der Website des Händlers mithilfe der sicheren Zahlungsbestätigung bestätigen.