--- url: 'https://www.corbado.com/de/blog/dynamische-verknuepfung-passkeys-spc' title: 'Dynamische Verknüpfung mit Passkeys: Secure Payment Confirmation (SPC)' description: 'Wir erklären, wie dynamische Verknüpfung, Passkeys und Secure Payment Confirmation (SPC) den digitalen Zahlungsverkehr verbessern. Erfahren Sie, wie Passkeys für die dynamische Verknüpfung eingesetzt werden und was die Zukunft bringt.' lang: 'de' author: 'Vincent Delitz' date: '2025-07-15T13:23:41.974Z' lastModified: '2026-03-27T07:03:03.317Z' keywords: 'dynamische verknüpfung, secure payment confirmation, spc, psd2' category: 'Passkeys Strategy' --- # Dynamische Verknüpfung mit Passkeys: Secure Payment Confirmation (SPC) ## 1. Einführung In unserer vierteiligen Serie (Teil 1, Teil 2, Teil 3 & Teil 4) zu [PSD2](https://www.corbado.com/blog/psd2-passkeys) haben wir untersucht, wie Passkeys in die Maßnahmen zur **starken Kundenauthentifizierung (SCA)** integriert werden, die durch [PSD2](https://www.corbado.com/blog/psd2-passkeys) eingeführt wurden. Dabei haben wir uns insbesondere auf die Authentifizierungselemente konzentriert, die von der [SCA](https://www.corbado.com/de/blog/passkeys-fuer-zahlungsanbieter-drittanbieter-sdk) für den Zugriff auf [Banking](https://www.corbado.com/de/blog/revolut-passkeys-analyse)-Anwendungen gefordert werden. [SCA](https://www.corbado.com/de/blog/passkeys-fuer-zahlungsanbieter-drittanbieter-sdk)-Anforderungen gelten nicht nur für den Zugriff auf Anwendungen, sondern auch für das Auslösen und Signieren von elektronischen [Zahlungstransaktionen](https://www.corbado.com/passkeys-for-payment) 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](https://www.corbado.com/de/blog/biometrie-payer-awareness) ist und wie wir Passkeys nutzen können, um diesen Mechanismus heute und in Zukunft umzusetzen. ## 2. Was ist die dynamische Verknüpfung in der PSD2? Die **dynamische Verknüpfung** ist eine Sicherheitsanforderung der [PSD2](https://www.corbado.com/blog/psd2-passkeys)-Richtlinie und ihrer ergänzenden Technischen Regulierungsstandards (RTS). Das Konzept wurde eingeführt, um die [Sicherheit](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) von elektronischen [Zahlungen](https://www.corbado.com/de/blog/digitale-nachweise-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](https://www.corbado.com/de/blog/digitale-nachweise-zahlungen) umfassen sowohl Banküberweisungen in Online-[Banking](https://www.corbado.com/de/blog/revolut-passkeys-analyse)-Software als auch Kreditkartenzahlungen auf [Merchant](https://www.corbado.com/glossary/merchant)-Websites. ### 2.1 Definition und Bedeutung in der PSD2 Gemäß der PSD2-Richtlinie und den begleitenden RTS wird die [dynamische Verknüpfung](https://www.corbado.com/de/blog/biometrie-payer-awareness) 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](https://www.corbado.com/passkeys-for-payment) zugestimmt hat“ (Artikel 97(2) der PSD2). Das bedeutet, dass jede Änderung der [Zahlungsdetails](https://www.corbado.com/passkeys-for-payment) den Authentifizierungscode ungültig machen und eine erneute Authentifizierung erfordern würde. Die [dynamische Verknüpfung](https://www.corbado.com/de/blog/biometrie-payer-awareness) 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. ### 2.2 Anforderungen an die dynamische Verknüpfung bei Finanztransaktionen 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](https://www.corbado.com/de/blog/digital-credentials-api) 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. ## 3. Wie können Passkeys für die dynamische Verknüpfung verwendet werden? Analysieren wir zunächst verschiedene Optionen, wie Passkeys bei der dynamischen Verknüpfung eingesetzt werden können. ### 3.1 Option 1: Standardmäßige Nutzung von Passkeys bei der dynamischen Verknüpfung Bei diesem Ansatz fungiert der Passkey selbst als kryptografische [Assertion](https://www.corbado.com/glossary/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. ### 3.2 Option 2: Erweiterter kryptografischer Nachweis durch die WebAuthn-Challenge 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](https://www.corbado.com/de/blog/digital-credentials-api) 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](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) in Hochrisiko-Transaktionsumgebungen erhöht (mehr Infos [hier](https://www.w3.org/2024/Talks/Fime_W3C_6feb24.pdf)). ### 3.3 Einschränkungen und Herausforderungen der Standard-Passkey-Optionen Analysieren wir die Einschränkungen und Herausforderungen dieser beiden Optionen. #### 3.3.1 Kenntnis des Zahlers kann nicht sichergestellt werden 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](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden). #### 3.3.2 Anwendungsfall: First-Party- vs. Third-Party-Zahlungskontext 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](https://www.corbado.com/glossary/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](https://www.corbado.com/de/blog/revolut-passkeys-analyse)-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](https://www.corbado.com/blog/mastercard-passkeys) 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](https://www.corbado.com/glossary/merchant) zeigt einen [Iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) an, in dem die Authentifizierung mit dem Passkey stattfinden kann. Der [IFRAME](https://www.corbado.com/blog/iframe-passkeys-webauthn) wird durch den zugrunde liegenden [3-D Secure](https://www.corbado.com/glossary/3d-secure) 2 (3DSS/EMV 3DS)-Prozess angezeigt, der bereits für Kreditkartentransaktionen vorhanden ist, die [SCA](https://www.corbado.com/de/blog/passkeys-fuer-zahlungsanbieter-drittanbieter-sdk) 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](https://www.corbado.com/glossary/merchant) den [Iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) 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](https://www.corbado.com/blog/iframe-passkeys-webauthn)-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: ![dynamic-linking-passkeys-check-out-faster.png](https://www.corbado.com/website-assets/dynamic_linking_passkeys_check_out_faster_edb79b9e22.png) **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](https://www.corbado.com/blog/iframe-passkeys-webauthn)-Iframes bereits in die laufende [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn)-Spezifikation (die bis Ende 2024 allgemein verfügbar sein wird) aufgenommen wurde. Allerdings müssen die Browser die Spezifikation noch umsetzen: | **Browser/Standard** | **First-Party-Kontext** | **Third-Party-Kontext** | | ----------------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | **Passkeys in Cross-Origin-Iframes registrieren:** | | | | Erforderlich in WebAuthn Level 2 | ✔️ [Details](https://issues.chromium.org/issues/40258856) | ❌ | | Erforderlich in WebAuthn Level 3 | ✔️ [Details](https://issues.chromium.org/issues/40258856) | ✔️ [Details](https://issues.chromium.org/issues/40258856) | | Implementiert in Chrome | ✔️ [Details](https://issues.chromium.org/issues/40258856) | ✔️ [Details](https://issues.chromium.org/issues/40258856) | | Implementiert in Firefox | ✔️ [Details](https://issues.chromium.org/issues/40258856) | [Positives Signal](https://github.com/mozilla/standards-positions/issues/964) für Implementierung | | Implementiert in [Safari](https://www.corbado.com/de/blog/digital-credentials-api) | ✔️ [Details](https://issues.chromium.org/issues/40258856) | Warten auf Signal für Implementierung | | **Mit Passkeys in Cross-Origin-Iframes authentifizieren:** | | | | Erforderlich in WebAuthn Level 2 | ✔️ | ✔️ | | Erforderlich in WebAuthn Level 3 | ✔️ | ✔️ | | Implementiert in Chrome | ✔️ | ✔️ | | Implementiert in Firefox | ✔️ | ✔️ | | Implementiert in Safari | ✔️ | ✔️ | Stand heute scheint es, dass bis 2024 die Abdeckung für die [Cross-Origin](https://www.corbado.com/blog/iframe-passkeys-webauthn)-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](https://www.corbado.com/de/blog/digitale-nachweise-zahlungen) aufheben würde. ## 4. Zukünftige Option: Secure Payment Confirmation (SPC) 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](https://www.corbado.com/passkeys-for-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. ### 4.1 Was sind die Ziele des SPC-Standards? [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) adressiert alle wichtigen Elemente der [PSD2 SCA](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden), einschließlich der Anforderung der dynamischen Verknüpfung, und versucht gleichzeitig, die UX zu verbessern. - **Browser-native UX bieten**: [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-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: ![Dynamic Linking Passkeys SPC Merchant](https://www.corbado.com/website-assets/dynamic_linking_passkeys_spc_merchant_8009b1ef5a.png)_Beispiel von [https://www.w3.org/press-releases/2023/spc-cr/](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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/dynamic-linking-passkeys-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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) entfernt. - **Cross-Origin-Authentifizierung von Zahlungen:** SPC erweitert den Nutzen von WebAuthn, indem es jeder Origin erlaubt, eine [Assertion](https://www.corbado.com/glossary/assertion) für eine Transaktion zu generieren, auch wenn sie Anmeldeinformationen von einer anderen [Relying Party](https://www.corbado.com/glossary/relying-party) nutzt (ohne die Seite verlassen zu müssen). In diesem Fall wird nicht einmal ein Iframe vom Merchant / [Issuer](https://www.corbado.com/glossary/issuer) benötigt. Diese Funktion ist besonders nützlich in Szenarien, in denen mehrere Parteien (Merchant + [Issuer](https://www.corbado.com/glossary/issuer) / Bank) am Authentifizierungsprozess beteiligt sind und die Assertion dann zur Überprüfung an die ursprüngliche [Relying Party](https://www.corbado.com/glossary/relying-party) (den Kontenanbieter, z. B. eine Bank) übermittelt werden kann. ![Cross Origin Authentication Payments](https://www.corbado.com/website-assets/cross_origin_authentication_payments_1fe18ec791.png) 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. ### 4.2 Wie würden die SPC-Passkey-Flows aussehen? 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. | | **SPC Passkeys** | **Passkeys** | | ------------------------------------------------------- | ---------------- | ------------ | | **Authentifizierung/Registrierung auf Issuer-Website** | ✔️ | ✔️ | | **Registrierung auf Merchant-Website im Iframe** | ✔️ | ❌/✔️ | | **Authentifizierung auf Merchant-Website im Iframe** | ✔️ | ✔️ | | **Cross-Origin-Authentifizierung auf Merchant-Website** | ✔️ | ❌ | 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. #### 4.2.1 SPC Passkeys: Registrierung / Authentifizierung direkt auf der Website des Issuers / der Bank Hier ist ein Mock-up-Beispiel für die Registrierung eines SPC-Passkeys direkt auf der Seite von [Mastercard](https://www.corbado.com/blog/mastercard-passkeys). Wie Sie hier sehen können, wird die Erstellung eines Passkeys direkt nach Abschluss der Authentifizierung per SMS-OTP in diesem Fall angeboten. ![SPC Passkeys Issuer Bank](https://www.corbado.com/website-assets/spc_passkeys_issuer_bank_3d68dd2043.png) In diesem Fall würde die Kommunikation wie ein Standard-Passkey-Registrierungsprozess aussehen, da dies vollständig im First-Party-Kontext geschieht. ![SPC Passkeys Flow](https://www.corbado.com/website-assets/spc_passkeys_flow_1324c4d2d7.png)_Entnommen aus [https://developer.chrome.com/docs/payments/register-secure-payment-confirmation](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. #### 4.2.2 SPC Passkeys: Registrierung / Authentifizierung auf einer Merchant-Website während der Zahlung 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](https://www.corbado.com/glossary/3d-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](https://www.corbado.com/de/blog/digital-credentials-api) 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](https://www.corbado.com/de/blog/passkeys-fuer-zahlungsanbieter-drittanbieter-sdk) oder der ausgebenden Bank (z. B. [mastercard](https://www.corbado.com/blog/mastercard-passkeys).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](https://www.corbado.com/de/faq/wie-werden-passkeys-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](https://www.corbado.com/de/blog/passkeys-fuer-zahlungsanbieter-drittanbieter-sdk) (z. B. [PayPal](https://www.corbado.com/blog/paypal-passkeys)) 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: ![SPC Passkeys Merchant Flow](https://www.corbado.com/website-assets/spc_passkeys_merchant_flow_267ffda65a.png)_Entnommen aus [https://developer.chrome.com/docs/payments/register-secure-payment-confirmation](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_ Unter [https://spc-merchant.glitch.me/](https://spc-merchant.glitch.me/) hat Google eine Demo-Anwendung eingerichtet, die über [Chrome](https://www.corbado.com/de/blog/digital-credentials-api) unter Windows und Mac aufgerufen werden kann und die veranschaulicht, wie dies aus einem Iframe heraus funktionieren würde: ![SPC Passkey Demo App](https://www.corbado.com/website-assets/spc_passkey_demo_app_4458eb6295.png) Es ermöglicht auch, direkt mit der Seite der Bank zu experimentieren, die unter [https://spc-rp.glitch.me/reauth](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. #### 4.2.3 SPC Passkeys: Cross-Origin-Authentifizierung 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. ![SPC Passkeys Cross-Origin Authentication](https://www.corbado.com/website-assets/spc_passkeys_cross_origin_authentication_3cc4d40619.png)_Ursprünglich von (teilweise angepasst): [https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf](https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf) (Mastercard)_ ![SPC Passkeys Cross-Origin Authentication Flow](https://www.corbado.com/website-assets/spc_passkeys_cross_origin_authentication_flow_d6d05cdf6b.png)_Ursprünglich von (teilweise angepasst): [https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams](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. ### 4.3 Wie ist der Status des Secure Payment Confirmation-Standards? Der [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (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](https://www.corbado.com/de/blog/digital-credentials-api) 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](https://www.corbado.com/de/blog/digital-credentials-api) und Mozilla [Firefox](https://www.corbado.com/de/blog/digital-credentials-api) 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. ## 5. Zukünftige Option 2: Die Confirmation Extension Die oben beschriebenen Herausforderungen, insbesondere im Hinblick auf die **Kenntnis des Zahlers**, haben zu laufenden Arbeiten in der [WebAuthn Working Group](https://github.com/w3c/webauthn/pull/2020) an einer sogenannten **Confirmation Extension** (früher bekannt als „txAuthSimple“) innerhalb des WebAuthN-Standards geführt. Ihr Ziel ist es, entweder dem [Authenticator](https://www.corbado.com/glossary/authenticator) oder dem Browser/Betriebssystem (in einer privilegierten UI) zu ermöglichen, die Transaktionsdetails dem Nutzer anzuzeigen und sicherzustellen, dass die [Relying Party](https://www.corbado.com/glossary/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](#331-kenntnis-des-zahlers-kann-nicht-sichergestellt-werden) beschriebene Problem der „fehlenden garantierten Nutzerkenntnis“. ### 5.1 Was sind die Ziele der Confirmation Extension? Ähnlich wie [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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. ### 5.2 Wie funktioniert die Confirmation Extension? Die Extension fügt den bestehenden WebAuthn-Extension-Strukturen ein neues Feld hinzu. Relying Parties liefern einen einfachen Textstring (mit optionaler Basisformatierung) namens `confirmation`: ```webidl 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](https://www.corbado.com/glossary/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. ### 5.3 Warum ist das für die dynamische Verknüpfung wichtig? 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. ### 5.4 Aktueller Status der Confirmation Extension 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](https://github.com/w3c/webauthn/pull/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. ### 5.5 Vergleich: Wie sich SPC und die Confirmation Extension unterscheiden 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: | **Vergleichskriterien** | **SPC** | **Confirmation Extension** | | ------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | **Integrierter Zahlungs-Flow**
_(Behandelt den gesamten Checkout, Beträge, Zahlungsempfänger, UI usw.)_ | ✔️ Beinhaltet einen standardisierten Browser-Dialog für Zahlungen | ❌ Konzentriert sich nur auf die Anzeige und Signierung eines Textstrings | | **Vertrauenswürdige Transaktionsanzeige**
_(Stellt sicher, dass der Nutzer den korrekten Zahlungsempfänger/Betrag sieht)_ | ✔️ Browser-basierter Flow sorgt für konsistente UX | ✔️ Entweder Authenticator-Anzeige oder Browser | | **Fallback-Handhabung**
_(Wenn der Authenticator begrenzte oder keine Anzeigefähigkeit hat)_ | ❌ Nicht speziell für Fallback-Pfade konzipiert | ✔️ Relying Party kann bei Bedarf eine Anzeige auf Client-Ebene akzeptieren | | **Umfang über dynamische Verknüpfung hinaus**
_(Breitere Ziele, z. B. Single-Click-Flows, Cross-Origin-Auth)_ | ✔️ Entwickelt, um den gesamten Checkout-Prozess zu optimieren | ❌ Strikt eine Erweiterung der Standard-WebAuthn-Challenge/Response | | **Aktuelle Reife & Verbreitung**
_(Cross-Browser-Bereitschaft)_ | Geringe Verbreitung über Chrome hinaus; unsicherer Zeitplan | In Diskussion in der [WebAuthn WG](https://github.com/w3c/webauthn/pull/2020), aber vielversprechend | 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. ## 6. Empfehlung für Issuer / Banken 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](https://issues.chromium.org/issues/40258856):** 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](https://www.corbado.com/passkeys-for-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. ## 7. Fazit 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](https://www.corbado.com/de/blog/digital-credentials-api) 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.