Dynamische Verknüpfung mit Passkeys: Secure Payment Confirmation (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

In unserer vierteiligen Serie (Teil 1, Teil 2, Teil 3 & Teil 4) zu PSD2 haben wir untersucht, wie Passkeys in die Maßnahmen zur starken Kundenauthentifizierung (SCA) integriert werden, die durch PSD2 eingeführt wurden. Dabei haben wir uns insbesondere auf die Authentifizierungselemente konzentriert, die von der SCA für den Zugriff auf Banking-Anwendungen gefordert werden. SCA-Anforderungen gelten nicht nur für den Zugriff auf Anwendungen, sondern auch für das Auslösen und Signieren von elektronischen Zahlungstransaktionen aus der Ferne. Darüber hinaus erfordern diese Vorschriften einen Mechanismus, der als dynamische Verknüpfung bekannt ist. In diesem Artikel erklären wir, was dynamische Verknüpfung ist und wie wir Passkeys nutzen können, um diesen Mechanismus heute und in Zukunft umzusetzen.

Die dynamische Verknüpfung ist eine Sicherheitsanforderung der PSD2-Richtlinie und ihrer ergänzenden Technischen Regulierungsstandards (RTS). Das Konzept wurde eingeführt, um die Sicherheit von elektronischen Zahlungen zu erhöhen. Es stellt sicher, dass jede Transaktion durch einen Authentifizierungscode eindeutig mit einem bestimmten Betrag und einem bestimmten Zahlungsempfänger verknüpft ist. Diese Verknüpfung verhindert, dass die Transaktionsdetails nach der Authentifizierung durch den Zahler geändert werden können, was das Betrugsrisiko verringert. Elektronische Zahlungen umfassen sowohl Banküberweisungen in Online-Banking-Software als auch Kreditkartenzahlungen auf Merchant-Websites.

Gemäß der PSD2-Richtlinie und den begleitenden RTS wird die dynamische Verknüpfung als ein Prozess definiert, der sicherstellt, dass „der generierte Authentifizierungscode spezifisch für den Betrag und den Zahlungsempfänger ist, denen der Zahler bei der Auslösung der elektronischen Zahlungstransaktion zugestimmt hat“ (Artikel 97(2) der PSD2). Das bedeutet, dass jede Änderung der Zahlungsdetails den Authentifizierungscode ungültig machen und eine erneute Authentifizierung erfordern würde.

Die dynamische Verknüpfung ist in der PSD2 von entscheidender Bedeutung, da sie direkt die Sicherheitsrisiken bei elektronischen Fernzahlungstransaktionen adressiert, die besonders anfällig für verschiedene Betrugsarten wie Man-in-the-Middle-Angriffe sind.

Durch die Absicherung der Transaktion auf diese Weise senkt die dynamische Verknüpfung die Wahrscheinlichkeit von unbefugten Transaktionen erheblich.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Artikel 5 der RTS führt die Anforderungen an den Authentifizierungscode bei der dynamischen Verknüpfung weiter aus. Zu diesen Anforderungen gehören:

• Kenntnis des Zahlers: Der Zahler wird über den Betrag der Zahlungstransaktion und den Zahlungsempfänger informiert.

• Einzigartigkeit des Authentifizierungscodes: Der für jede Transaktion generierte Authentifizierungscode muss einzigartig sein und darf für keine andere Transaktion wiederverwendet werden.

• Spezifität des Authentifizierungscodes: Die generierten und akzeptierten Codes müssen spezifisch für den Transaktionsbetrag und die Identität des vom Zahler bestätigten Zahlungsempfängers sein. Jede Änderung des Betrags oder des Zahlungsempfängers führt zur Ungültigkeit des Authentifizierungscodes.

• Sichere Übertragung: Vertraulichkeit, Authentizität und Integrität des Transaktionsbetrags und des Zahlungsempfängers müssen in allen Phasen der Authentifizierung, einschließlich der Erzeugung, Übertragung und Verwendung des Authentifizierungscodes, gewahrt bleiben.

Nachdem wir die technischen Anforderungen der dynamischen Verknüpfung dargelegt haben, sehen wir uns im nächsten Abschnitt an, wie Passkeys als neue Technologie helfen können. Wir werden ihr Potenzial untersuchen, Zahlungsvorgänge zu optimieren und abzusichern, wodurch die dynamische Verknüpfung nicht nur robuster, sondern auch benutzerfreundlicher wird.

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.

Unternehmen vertrauen auf Corbado, um ihre Nutzer zu schützen und Logins mit Passkeys nahtloser zu gestalten. Holen Sie sich jetzt Ihre kostenlose Passkey-Beratung.

Kostenlose Beratung erhalten

Analysieren wir zunächst verschiedene Optionen, wie Passkeys bei der dynamischen Verknüpfung eingesetzt werden können.

Bei diesem Ansatz fungiert der Passkey selbst als kryptografische Assertion, die direkt als Authentifizierungscode verwendet wird. Die während des Transaktionsprozesses ausgegebene Challenge wird so generiert, dass sie die spezifischen Transaktionsdetails wie Betrag und Zahlungsempfänger widerspiegelt und zusammen mit diesen Informationen gespeichert wird. Wenn der Nutzer die Transaktion mit seinem Passkey autorisiert, wird eine einzigartige, kryptografisch sichere Signatur erzeugt, die verifiziert und zusammen mit der Transaktion gespeichert werden kann. Diese Antwort dient nicht nur als robuster Authentifizierungsfaktor, sondern verknüpft die Genehmigung auch direkt mit den spezifischen Transaktionsdetails und erfüllt damit strikt die Anforderungen der PSD2 an die dynamische Verknüpfung.

Become part of our Passkeys Community for updates & support.

Join

Eine fortgeschrittenere Integration beinhaltet die Kodierung zusätzlicher Transaktionsdetails in die WebAuthn-Challenge selbst (was technisch nicht von der PSD2/RTS gefordert wird). Diese Methode schlägt vor, einen kryptografischen Hash des Zahlungsempfängers und des Betrags zusammen mit anderen zufälligen Daten in die Challenge zu integrieren. Dadurch verifiziert der Authentifizierungsprozess nicht nur die Identität des Nutzers durch den Passkey, sondern bestätigt auch kryptografisch die Integrität der Transaktionsdetails. Dieser Ansatz bietet eine zusätzliche Sicherheitsebene, indem er sicherstellt, dass jede Manipulation des Betrags oder der Zahlungsempfängerdetails bei der endgültigen Zahlung erkennbar wäre. Der kryptografische Nachweis wird zu einem unveränderlichen Teil des Authentifizierungscodes, was das Vertrauen und die Sicherheit in Hochrisiko-Transaktionsumgebungen erhöht (mehr Infos hier).

Analysieren wir die Einschränkungen und Herausforderungen dieser beiden Optionen.

Eine der Einschränkungen bei der Verwendung von Passkeys im Kontext der dynamischen Verknüpfung, insbesondere bei der Zahlungsauthentifizierung, ist die fehlende konkrete Dokumentation oder Zusicherung, dass der Zahler korrekt über die Informationen zum Zahlungsempfänger informiert wurde.

Obwohl Passkeys eine sichere Methode zur Nutzerauthentifizierung bieten, überprüfen sie nicht von sich aus, ob alle Transaktionsdetails, insbesondere die des Zahlungsempfängers, dem Zahler korrekt angezeigt wurden.

Dieses Problem ist nicht auf Passkeys beschränkt; es ist eine allgemeine Herausforderung bei verschiedenen Online-Zahlungssystemen. Sicherzustellen, dass der Zahler vor der Zahlungsauslösung vollständig über alle Transaktionsdetails informiert ist und diesen zustimmt, ist entscheidend für die Aufrechterhaltung von Vertrauen und Sicherheit.

Die größte Einschränkung bei der Integration von Passkeys in die dynamische Verknüpfung ergibt sich aus der Unterscheidung zwischen First-Party- und Third-Party-Registrierung.

Was ist ein First-Party-Zahlungskontext?

✔️ Im First-Party-Zahlungskontext interagiert der Nutzer direkt mit dem Issuer / der Bank auf deren Internetdienst und Domain. Passkeys können nahtlos registriert und authentifiziert werden. Ein Beispiel wäre eine Bank, die einen Passkey auf ihrer eigenen Website registriert und ihn zur Autorisierung einer Zahlungsauslösung aus ihrer Online-Banking-Software verwendet. Hier funktionieren Passkeys reibungslos. Die Bank kann sicherstellen, dass der Passkey innerhalb ihrer Domain verwendet wird, und behält so die Kontrolle über die Zahlungsumgebung und die Sicherheit der Transaktion.

Lesen Sie dazu unseren Blogbeitrag über die Passkey-Implementierung von Mastercard in einem First-Party-Zahlungskontext.

Was ist ein Third-Party-Zahlungskontext?

Im Third-Party-Zahlungskontext befindet sich der Nutzer auf der Seite eines Merchants im Checkout-Prozess auf einer anderen Domain (z. B. amazon.com) und möchte eine Kreditkartentransaktion initiieren:

• ✔️ Fall 1 – Der Nutzer hat bereits einen Passkey von seinem Issuer / seiner Bank: Der Merchant zeigt einen Iframe an, in dem die Authentifizierung mit dem Passkey stattfinden kann. Der IFRAME wird durch den zugrunde liegenden 3-D Secure 2 (3DSS/EMV 3DS)-Prozess angezeigt, der bereits für Kreditkartentransaktionen vorhanden ist, die SCA und dynamische Verknüpfung unterstützen müssen.

• ❌ Fall 2 – Der Nutzer hat noch keinen Passkey von seinem Issuer / seiner Bank: Wiederum zeigt der Merchant den Iframe an. Da noch keine Passkeys verfügbar sind, wird der Nutzer durch bestehende Authentifizierungsfaktoren (z. B. SMS-OTP oder die native Banking-App auf seinem Smartphone) authentifiziert. An diesem Punkt, nach einer erfolgreichen Authentifizierung, wäre es der ideale Moment, einen Passkey für den Nutzer zu registrieren, aber dies ist jedoch aufgrund von Einschränkungen des WebAuthn-Standards nicht erlaubt. Die Registrierung von Passkeys in einem Cross-Origin-Iframe ist nicht erlaubt (die Domain der Hauptseite und des Iframes müssten identisch sein). Eine schrittweise Registrierung wie im folgenden Screenshot wäre unmöglich:

Wird die Passkey-Registrierung in Cross-Origin-Iframes in Zukunft unterstützt?

Während Passkeys eine gute Lösung für die dynamische Verknüpfung im First-Party-Zahlungskontext innerhalb einer einzigen Domain bieten, werden sie im Third-Party-Zahlungskontext derzeit von WebAuthn Level 2 nicht unterstützt. Die gute Nachricht ist jedoch, dass die Unterstützung für Cross-Origin-Iframes bereits in die laufende WebAuthn Level 3-Spezifikation (die bis Ende 2024 allgemein verfügbar sein wird) aufgenommen wurde. Allerdings müssen die Browser die Spezifikation noch umsetzen:

Stand heute scheint es, dass bis 2024 die Abdeckung für die Cross-Origin-Registrierung von Passkeys in den großen Browsern Realität werden könnte, was die größte technische Einschränkung bei der Verwendung von Passkeys für Zahlungen aufheben würde.

Es gab mehrere Versuche von Google-initiierten Arbeitsgruppen beim W3C (z. B. BasicCard, PaymentHandler oder PaymentManifest), das Zahlungserlebnis im Web zu verbessern. Bisher hat keiner eine signifikante Marktabdeckung und Nutzung erreicht. Reibungsverluste im Zahlungsprozess bei E-Commerce-Transaktionen bleiben eine große Herausforderung bei zunehmender Regulierung gegen Betrug. Der Secure Payment Confirmation-Standard, der von Google & Stripe initiiert wurde, ist derzeit der vielversprechendste Standard, der auf dem WebAuthn-Standard aufbaut.

Secure Payment Confirmation (SPC) adressiert alle wichtigen Elemente der PSD2 SCA, einschließlich der Anforderung der dynamischen Verknüpfung, und versucht gleichzeitig, die UX zu verbessern.

• Browser-native UX bieten: SPC nutzt den Browser, um ein konsistentes und optimiertes Authentifizierungserlebnis über verschiedene Merchant-Seiten und Relying Parties hinweg zu bieten. Dieser Ansatz soll die Transaktionssicherheit über das hinaus verbessern, was typischerweise mit in einem Iframe gerenderten Inhalten erreicht wird, indem ein einheitliches Erscheinungsbild und die Kenntnisnahme durch den Zahler gewährleistet werden:

Beispiel von https://www.w3.org/press-releases/2023/spc-cr/

• Kryptografischen Nachweis liefern: Der Standard stellt sicher, dass ein kryptografischer Nachweis der Bestätigung der Zahlungsdetails durch den Nutzer generiert und in die WebAuthn-Assertion aufgenommen wird, ohne dass die Informationen in die WebAuthn-Challenge kodiert werden müssen.

• Third-Party-Registrierung ermöglichen: Anders als im WebAuthn Level 2-Standard, wo die Registrierung eines Authenticators in einem First-Party-Kontext erfolgen muss, ermöglicht SPC die Registrierung von Passkeys direkt aus einem Cross-Origin-Iframe. Diese Fähigkeit adressiert gängige Anwendungsfälle im Zahlungsökosystem und erleichtert die Integration für Merchants und Zahlungsabwickler. Wie wir oben besprochen haben, ist diese Funktionalität bereits Teil der nächsten Version des zugrunde liegenden Standards und wird daher wahrscheinlich in Zukunft aus SPC entfernt.

• Cross-Origin-Authentifizierung von Zahlungen: SPC erweitert den Nutzen von WebAuthn, indem es jeder Origin erlaubt, eine Assertion für eine Transaktion zu generieren, auch wenn sie Anmeldeinformationen von einer anderen Relying Party nutzt (ohne die Seite verlassen zu müssen). In diesem Fall wird nicht einmal ein Iframe vom Merchant / Issuer benötigt. Diese Funktion ist besonders nützlich in Szenarien, in denen mehrere Parteien (Merchant + Issuer / Bank) am Authentifizierungsprozess beteiligt sind und die Assertion dann zur Überprüfung an die ursprüngliche Relying Party (den Kontenanbieter, z. B. eine Bank) übermittelt werden kann.

Das obige Beispiel stammt aus dem SPC Explainer und zeigt das Konzept der Cross-Origin-Authentifizierung von Zahlungen: In einem Zahlungsprozess mit SPC bleibt der Nutzer während der gesamten Transaktion auf der Website des Merchants (blau hervorgehoben). Der Webbrowser (grün gefärbt) behält die Anzeige der Origin des Merchants bei und präsentiert auch einen vordefinierten, nicht anpassbaren Dialog mit allen wichtigen Informationen für die dynamische Verknüpfung (Betrag + Zahlungsempfänger) zur Bestätigung der Transaktion. Nach der Bestätigung durch den Nutzer übernimmt das Betriebssystem (orange dargestellt) die biometrische Authentifizierung, die zur Überprüfung der Transaktion erforderlich ist.

Diese Ziele verdeutlichen das Engagement von SPC, sowohl die Sicherheit als auch das Nutzererlebnis bei Online-Zahlungen zu verbessern, mit dem Ziel, Authentifizierungsprozesse zu vereinfachen und gleichzeitig hohe Sicherheitsstandards im gesamten digitalen Zahlungsverkehr aufrechtzuerhalten.

Gehen wir alle möglichen Flows durch, die SPC ermöglichen würde, und vergleichen wir sie mit Standard-Passkeys, um die Vorteile zu verstehen.

Wie wir hier sehen, ist der wichtigste Unterschied die Registrierung auf der Merchant-Website innerhalb eines Iframes, die von Passkeys noch nicht unterstützt wird (siehe unsere obige Diskussion), und die völlig neue Möglichkeit der Cross-Origin-Authentifizierung. Gehen wir sie einzeln durch.

Hier ist ein Mock-up-Beispiel für die Registrierung eines SPC-Passkeys direkt auf der Seite von Mastercard. Wie Sie hier sehen können, wird die Erstellung eines Passkeys direkt nach Abschluss der Authentifizierung per SMS-OTP in diesem Fall angeboten.

In diesem Fall würde die Kommunikation wie ein Standard-Passkey-Registrierungsprozess aussehen, da dies vollständig im First-Party-Kontext geschieht.

Entnommen aus https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

Dieser SPC-Passkey könnte nun auf einer Merchant-Seite zur Authentifizierung, in einem Iframe auf der Merchant-Seite und für die Cross-Origin-Authentifizierung (siehe unten) verwendet werden.

Wie wir bereits besprochen haben, würde der Prozess der Registrierung eines SPC-Passkeys auf einer Merchant-Website typischerweise während der Zahlungstransaktion im Kontext des 3-D Secure (3DS)-Flows stattfinden. Dieser Flow wurde entwickelt, um die Sicherheit von Online-Kredit- und Debitkartentransaktionen zu erhöhen, indem ein zusätzlicher Authentifizierungsschritt zur Überprüfung der Identität des Karteninhabers eingeführt wird.

Während einer Zahlungstransaktion, wenn der 3DS-Flow initiiert wird, wird der Authentifizierungsprozess durch einen Iframe erleichtert, der auf der Website des Merchants (z. B. amazon.com) gehostet, aber vom Zahlungsdienstleister oder der ausgebenden Bank (z. B. mastercard.com) kontrolliert wird. Dieser Iframe dient als sichere Umgebung für den Kunden, um seine Identität mit bestehenden Authentifizierungsfaktoren zu authentifizieren.

Sobald sich der Kunde mit diesen herkömmlichen Faktoren (z. B. SMS-OTP oder Banking-App) erfolgreich authentifiziert hat, besteht die Möglichkeit, einen SPC-Passkey für zukünftige Transaktionen zu registrieren. Da der SPC-Standard die Cross-Origin-Passkey-Erstellung aus Iframes heraus erlaubt, würde dies funktionieren. Die Registrierung dieses Passkeys im Iframe würde typischerweise beinhalten, dass der Kunde eine Aktion durchführt, die den Passkey generiert und an seine Kreditkarte bindet, wie z. B. die Überprüfung seines Fingerabdrucks oder seiner Gesichtserkennung auf einem kompatiblen Gerät. Beachten Sie, dass der Iframe vom Zahlungsdienstleister (z. B. PayPal) oder der ausgebenden Bank (z. B. mastercard.com) kontrolliert wird. Daher wird der SPC-Passkey direkt beim Issuer / der Bank und nicht beim Merchant erstellt. Der vereinfachte Flow würde so aussehen:

Entnommen aus https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

Unter https://spc-merchant.glitch.me/ hat Google eine Demo-Anwendung eingerichtet, die über Chrome unter Windows und Mac aufgerufen werden kann und die veranschaulicht, wie dies aus einem Iframe heraus funktionieren würde:

Es ermöglicht auch, direkt mit der Seite der Bank zu experimentieren, die unter https://spc-rp.glitch.me/reauth gehostet wird. In diesem Beispiel ist keine Out-of-Band-Kommunikation mit APIs zwischen dem Merchant und dem Issuer / der Bank erforderlich – alles wird vom Browser gehandhabt. Die Authentifizierung mit einem vorhandenen Passkey würde auf die gleiche Weise aus dem Iframe heraus funktionieren.

Im folgenden Beispiel sehen wir die Cross-Origin-Authentifizierung, bei der der Nutzer bereits einen SPC-Passkey bei Mastercard registriert hat. Die Beispiel-Merchant-Seite (decorshop.com) kann die Cross-Origin-Authentifizierung auslösen. Der wesentliche und wichtige Unterschied besteht darin, dass die Seite des Merchants / Issuers während des Authentifizierungsprozesses niemals sichtbar ist. Der Browser in Kombination mit dem Betriebssystem präsentiert die vordefinierte Zahlungs-UX (bereitgestellt durch die Browser-Implementierung des SPC-Standards) und das Authentifizierungsmodal (WebAuthn-Standard). Die Kommunikation zwischen Merchant und Issuer / Bank wird im Hintergrund abgewickelt.

Ursprünglich von (teilweise angepasst): https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (Mastercard)

Ursprünglich von (teilweise angepasst): https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams

Bei der Cross-Origin-Authentifizierung kommuniziert der Merchant mit dem Issuer / der Bank über eine Art API, um Informationen über vorhandene Anmeldeinformationen auszutauschen (#2 im Sequenzdiagramm oben). Wenn Anmeldeinformationen vorhanden sind und der Browser des Nutzers SPC unterstützt, beginnt die Authentifizierung. Am Ende wird die Assertion über bestehende Protokolle wie EMV 3DS an den Issuer / die Bank zurückgesendet, wo die Assertion am Ende kryptografisch verifiziert werden kann (#16).

Da die Assertion auch Informationen über die vom Browser angezeigten Informationen enthält, sind alle Anforderungen für die dynamische Verknüpfung erfüllt. Dies wäre ein großer Schritt in Bezug auf UX und die Verbesserung des Kundenzahlungserlebnisses.

Der Secure Payment Confirmation (SPC)-Standard ist eine interessante Entwicklung in der Welt der Online-Zahlungsauthentifizierung, die darauf abzielt, die Sicherheit zu erhöhen und gleichzeitig das Nutzererlebnis zu optimieren. Stand heute ist Google Chrome der einzige große Browser, der SPC in irgendeiner Form unterstützt. Dies ist jedoch nicht überraschend, da der Standard teilweise von Google initiiert wurde. Von anderen großen Browsern wie Apples Safari und Mozilla Firefox gibt es ein bemerkenswertes Fehlen von Engagement ohne klare Signale über ihre Pläne zur Unterstützung von SPC. Insbesondere Apple forciert seinen eigenen proprietären Standard Apple Pay und scheint an anderen Zahlungsstandards nicht interessiert zu sein.

Die Verbindung von SPC mit WebAuthn hat den Entwicklungsprozess erschwert. Dies liegt daran, dass alle Verbesserungen oder Änderungen am SPC-Standard sorgfältig bewertet werden müssen, um Redundanzen zu vermeiden und sicherzustellen, dass sie echte Verbesserungen gegenüber den bestehenden Fähigkeiten bieten. Das Ziel ist es, SPC so zu verfeinern, dass es spezifische Bedürfnisse im Zahlungsprozess erfüllt, die von WebAuthn nicht vollständig abgedeckt werden, wie z. B. die direkte Integration in den Checkout-Flow und die Bereitstellung eines benutzerfreundlicheren Authentifizierungserlebnisses, das nahtlos über verschiedene Merchant-Seiten hinweg funktioniert.

Während sich SPC weiterentwickelt, wird seine Akzeptanz in verschiedenen Browsern für eine breite Implementierung entscheidend sein. Die Beteiligung großer Akteure wie Google deutet auf eine positive Richtung hin, aber eine breitere Unterstützung wird notwendig sein, um SPC als Standard in der gesamten Online-Zahlungsbranche zu etablieren.

Die oben beschriebenen Herausforderungen, insbesondere im Hinblick auf die Kenntnis des Zahlers, haben zu laufenden Arbeiten in der WebAuthn Working Group an einer sogenannten Confirmation Extension (früher bekannt als „txAuthSimple“) innerhalb des WebAuthN-Standards geführt. Ihr Ziel ist es, entweder dem Authenticator oder dem Browser/Betriebssystem (in einer privilegierten UI) zu ermöglichen, die Transaktionsdetails dem Nutzer anzuzeigen und sicherzustellen, dass die Relying Party einen kryptografischen Nachweis erhält, dass der Nutzer diese Details tatsächlich bestätigt hat. Dies adressiert direkt das in Abschnitt 3.3.1 beschriebene Problem der „fehlenden garantierten Nutzerkenntnis“.

Ähnlich wie Secure Payment Confirmation (SPC) einen dedizierten, browsergesteuerten Dialog bereitstellt, geht die Confirmation Extension das „What You See Is What You Sign“ (WYSIWYS)-Problem an. Ihre Hauptziele sind:

• Vertrauenswürdige Anzeige von Transaktionsdetails: Anstatt es dem Webinhalt zu überlassen, Betrag und Zahlungsempfänger anzuzeigen, nutzt die Extension entweder den sicheren Bildschirm eines Geräts oder einen Browser-UI-Dialog unter der Kontrolle des Betriebssystems.
• Kryptografischer Nachweis: Der Authenticator (oder die Client-Plattform) signiert eine Aufzeichnung des exakten angezeigten Textes. Durch die Überprüfung dieser Signatur kann die Relying Party bestätigen, dass dem Nutzer die korrekten Details angezeigt wurden.
• Fallback, falls der Authenticator keine Anzeige unterstützt: In Fällen, in denen ein Hardware-Authenticator keinen Text anzeigen kann, kann der Browser ihn anzeigen und in die (=client data=] aufnehmen. Dies ist eine schwächere Garantie, ermöglicht aber eine breitere Kompatibilität.

Die Extension fügt den bestehenden WebAuthn-Extension-Strukturen ein neues Feld hinzu. Relying Parties liefern einen einfachen Textstring (mit optionaler Basisformatierung) namens confirmation:

partial dictionary AuthenticationExtensionsClientInputs {
  USVString confirmation;
};

Wenn der Client (Browser) dies empfängt, wird er:

1. Den Nutzer mit einem speziellen Bestätigungsdialog auffordern (damit er weiß, dass dies mehr als ein einfacher Login ist).
2. Denselben String als CBOR-Daten an den Authenticator weitergeben, wenn der Authenticator die Extension unterstützt.
3. Jegliche Authenticator-Ausgabe an die Relying Party zurückgeben.

Wenn der Authenticator die Anzeige von Text unterstützt, muss er diesen Text anzeigen (z. B. auf seinem eigenen Bildschirm oder einer vertrauenswürdigen UI), bevor er die Nutzerverifizierung abschließt. Er fügt dann denselben String in seine signierte Ausgabe ein.

Auf Seiten der Relying Party stellen die Verifizierungsschritte sicher, dass der zurückgegebene confirmation-Text mit dem gesendeten übereinstimmt. Wenn die Authenticator-Extension-Ausgabe fehlt, die Richtlinie der Relying Party aber einen Fallback erlaubt, kann sich die Relying Party auf den confirmation-Wert aus den Client-Daten verlassen – was anzeigt, dass der Browser den Text anstelle des Authenticators angezeigt hat.

Durch die Einbettung von Zahlungsempfänger und Betrag in diese Extension sieht der Nutzer auf einer vertrauenswürdigen Anzeige genau, was er autorisiert. Die Signatur des Nutzers spiegelt nun nicht nur eine gehashte Challenge wider, sondern auch den exakten Transaktionstext. Dies ist besonders wertvoll für die Anforderung der dynamischen Verknüpfung der PSD2, da:

• Jede Nichtübereinstimmung oder Änderung der Transaktionsdetails nach der Anzeige die Signatur ungültig macht.
• Die Relying Party nachweisen kann, dass dem Nutzer zum Zeitpunkt der Signierung die korrekten Transaktionsdetails vorgelegt wurden, was die PSD2-Anforderung der „Kenntnis des Zahlers“ weitaus robuster erfüllt als nur das Hashen von Daten in der Challenge.

Obwohl die Confirmation Extension noch in der Diskussion ist, stellt sie einen entscheidenden Schritt in Richtung sichererer und benutzerfreundlicherer Transaktionsabläufe dar. Indem sie direkt in die WebAuthn-Spezifikation integriert wird, bietet sie:

• Interoperabilität: Jeder Authenticator oder Client, der die Extension implementiert, würde demselben standardisierten Format folgen.
• Flexibilität: Relying Parties können strengere Richtlinien durchsetzen (die eine Anzeige auf Authenticator-Ebene erfordern) oder bei Bedarf einen Fallback auf Browser-Ebene akzeptieren.
• Breitere Ökosystem-Ausrichtung: Sie passt gut zu regulatorischen Vorgaben wie der PSD2, insbesondere im Hinblick auf eine robuste dynamische Verknüpfung.

Für weitere technische Details können Sie einen Blick in die laufende Diskussion werfen: GitHub Pull Request #2020. Zusammenfassend könnte die Confirmation Extension auch die letzte große Lücke in standardmäßigen Passkey-basierten Abläufen schließen: die Bereitstellung eines kryptografischen Nachweises darüber, was der Nutzer genau gesehen hat, als er seine Zustimmung gab, wenn auch weniger strukturiert als bei der Secure Payment Confirmation. Sollte sie bei Browsern und Authenticator-Herstellern Anklang finden, könnte sie zu einer hochgradig standardisierten Methode werden, um die unter der PSD2 für die dynamische Verknüpfung erforderliche WYSIWYS-Sicherheitsgarantie zu liefern – und darüber hinaus.

Obwohl SPC und die Confirmation Extension das gemeinsame Ziel verfolgen, die dynamische Verknüpfung in WebAuthn zu stärken, unterscheiden sie sich in Umfang und Ansatz. Die folgende Tabelle hebt einige dieser Unterschiede hervor:

Im Wesentlichen versucht SPC, eine umfassende Zahlungslösung anzubieten und integriert die dynamische Verknüpfung als Teil seines Flows. Die Confirmation Extension hingegen adressiert die „What you see is what you sign“-Anforderung innerhalb von Standard-WebAuthn-Nachrichten, ohne einen vollständigen Zahlungs-Flow aufzuzwingen. Beide Ansätze könnten die PSD2-Konformität erleichtern, aber jeder hängt von der Unterstützung durch Browser und Authenticator ab, um reale Vorteile zu erzielen.

Unsere Empfehlung für Issuer, Banken und Finanzinstitute lautet daher, sorgfältig zu prüfen, welche Anwendungsfälle abgedeckt werden müssen, und die Entwicklung des Ökosystems zu beobachten. Die Einfachheit von Passkeys wird erheblichen Druck auf bestehende SCA- und dynamische Verknüpfungslösungen ausüben, ihre UX zu verbessern. Kunden werden biometrische Lösungen im Web fordern. Im Moment lautet unsere operative Empfehlung:

• ✔️ Passkeys für Zahlungen, die auf der Website des Issuers / der Bank initiiert werden: Passkeys sind eine sehr gute Lösung für Issuer / Banken, um die dynamische Verknüpfung direkt in ihre Websites und Apps zu implementieren. Sie könnten mit anderen Authentifizierungsoptionen wie Push-Benachrichtigungen, E-Mail-/SMS-OTP oder TOTP kombiniert werden, um die Sicherheit bei Hochrisikozahlungen weiter zu erhöhen. Natürlich sollten Überlegungen zur SCA-Konformität immer Teil dieser Diskussion sein (siehe auch unsere vierteilige Serie zu Passkeys & SCA).

  Eine vorgeschlagene Lösung kann von den Issuern / Banken selbst implementiert werden, da Passkeys auf dem offenen WebAuthn-Standard basieren. Dies erfordert jedoch erhebliches Know-how, den Umgang mit Edge Cases und die kontinuierliche Auseinandersetzung mit allen neuen Vorschriften und technischen Entwicklungen. Die Alternative ist die Nutzung eines externen Authentifizierungsanbieters. Corbado Connect unterstützt beispielsweise die dynamische Verknüpfung durch Transaktionssignierung, bei der angepasste WebAuthn-Challenges genutzt werden. Alle Informationen werden im Audit-Log protokolliert. Dies ist nicht nur für Finanzinstitute nützlich, sondern kann für alle Arten von Signaturen (z. B. Dokumentensignierung, Hochrisiko-Nutzeraktionen) genutzt werden. Optional kann ein zusätzliches SMS- oder E-Mail-OTP verwendet werden, um die Sicherheit noch weiter zu verbessern.

• ❌ Passkeys für Zahlungen auf Merchant-Seiten: Die Einführung von Passkeys für Zahlungen auf Merchant-Seiten ist noch nicht möglich. Cross-Origin-Anwendungsfälle befinden sich noch in der Entwicklung, könnten aber Ende 2024 eine praktikable Option sein. Die Verwendung von Passkeys zur Authentifizierung auf Merchant-Seiten ist jedoch bereits heute eine großartige Idee und kann auch genutzt werden, um mit dem Sammeln von Passkeys zu beginnen, die dann in Zukunft auch für Zahlungen verwendet werden können.

• ❌ SPC Passkeys oder Confirmation Extension für dynamische Verknüpfung: Der SPC-Standard hat noch keinen ausgereiften Zustand und keine ausreichende Unterstützung erreicht, um in Produktionsumgebungen eingesetzt zu werden.

Insgesamt freuen wir uns zu sehen, dass Merchants und Banken begonnen haben, sich mit dem Standard auseinanderzusetzen und ihre Anforderungen und Unterstützung in das Ökosystem einzubringen. Mit Blick auf die Zukunft sollten Finanzinstitute und E-Commerce-Plattformen diese technologischen Fortschritte genau beobachten und überlegen, wie sie Passkeys in ihre Systeme integrieren könnten. Da sich die Vorschriften weiterentwickeln, ist es entscheidend, immer einen Schritt voraus zu sein und sicherzustellen, dass die Zahlungsauthentifizierungsprozesse den neuesten Sicherheitsstandards entsprechen und den Verbrauchern ein sicheres, effizientes Nutzererlebnis bieten, das die Konversion verbessert und Reibungsverluste reduziert.

Warum sind Passkeys wichtig?

Passkeys für Unternehmen

Passwörter & Phishing stellen ein Risiko für Unternehmen dar. Passkeys sind die einzige MFA-Lösung, die Sicherheit und UX in Einklang bringt. Unser Whitepaper behandelt Implementierung und Business-Impact.

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

Wenn wir Passkeys für die dynamische Verknüpfung betrachten, wird deutlich, dass Passkeys zwar helfen können, SCA und dynamische Verknüpfung einzuhalten, die technische Integration in Drittanbieter-Dienste mit dem WebAuthn-Standard, der ursprünglich für First-Party-Kontexte konzipiert wurde, jedoch einige Herausforderungen mit sich bringt. Diese Standards entwickeln sich allmählich weiter, um Third-Party-Szenarien besser zu unterstützen, was einen Wandel hin zu größerer Flexibilität in ihrer Anwendung zeigt. Secure Payment Confirmation (SPC) versucht, diese Anpassung weiter voranzutreiben, mit dem Ziel, die Zahlungsauthentifizierungsprozesse durch die Einbeziehung benutzerfreundlicherer und nahtloserer Interaktionen über verschiedene Merchant-Seiten hinweg zu verbessern.

Die Weiterentwicklung und breitere Akzeptanz des SPC-Standards oder der Confirmation Extension hängt jedoch stark von ihrer Übernahme durch die großen Browser ab – ein Prozess, der langsam verläuft, wobei Google Chrome derzeit der einzige Unterstützer ist. Diese langsame Adaptionsrate könnte insbesondere SPC daran hindern, über seinen aktuellen Zustand hinauszukommen, es sei denn, mehr Browser beginnen, es zu integrieren. Die laufende Entwicklung und die zunehmende Verbreitung von Passkeys deuten auf eine vielversprechende Richtung hin, in der Systeme, die auf Hardware-Sicherheitsmodulen (HSMs) wie Secure Enclaves, TEEs und TPMs basieren, auch für Zahlungsanwendungen eine wichtige Rolle spielen werden. Denn diese Technologien bieten eine erhöhte Sicherheit, die die dynamische Verknüpfung von Zahlungen nicht nur für Transaktionen, die auf Banking-Websites initiiert werden, sondern auch auf Drittanbieter-Merchant-Plattformen praktischer und komfortabler machen könnte.

Das Potenzial von Passkeys, ihren Nutzen auf Online-Zahlungsprozesse auszuweiten, unterstreicht einen wichtigen Aspekt bei der Absicherung webbasierter Transaktionen und macht das Internet insgesamt zu einem sichereren Ort.