Zahlungen mit der EUDI-Wallet bestätigen: TS12 Dynamic Linking auf Ihrem eigenen Mandanten

Die kurze Antwort

Was

OpenID4VP-Anfragen mit TS12-Transaktionsdaten – Zahlung, Anmeldung oder riskante Aktion, Zugriff auf Kontoinformationen, E-Mandat – und die Prüfung der Antwort der Wallet.

Geprüft

Das TS12-Datenmodell der Transaktion, die Hashes genau der gesendeten Einträge, ein einmaliger Authentifizierungscode, zwei Authentifizierungsfaktoren, der Response-Mode und die Zahlungskarte selbst (Aussteller, Signatur, Sperrstatus).

Ergebnis

Der Authentifizierungscode, die verwendeten Faktoren, die Transaktions-IDs und nur die angefragten Kartenattribute. Niemand wird angemeldet, kein Konto wird angelegt.

Wo

Ihr CodeB-Mandant in der EU. Die Person braucht eine Wallet, die TS12 umsetzt, und eine Zahlungskarte (SCA-Attestation) ihrer Bank.

Die vier TS12-Transaktionstypen

Jede Wallet, die TS12 umsetzt, muss diese vier Typen anzeigen und signieren. Eigene Typnamen Ihrer Bank lassen sich darauf abbilden.

So funktioniert es

Derselbe OpenID4VP-Ablauf wie bei der Anmeldung mit der Wallet, mit der Transaktion in der signierten Anfrage.

Die API

Beispiel

# 1. One transaction_data entry per transaction (TS12 payload), base64url-encoded
{
  "type": "urn:eudi:sca:payment:1",
  "credential_ids": ["ts12_sca"],
  "transaction_data_hashes_alg": ["sha-256"],
  "payload": {
    "transaction_id": "8D8AC610-566D-4EF0-9C22-186B2A5ED793",
    "payee": {"name": "Demo Shop", "id": "DE02120300000000202051"},
    "currency": "EUR",
    "amount": 12.50
  }
}

# 2. Start the request (transaction_data = base64url of the JSON array of the base64url entries)
GET /oidc.ashx?action=vp-start&query=sca&vct=<SCA attestation type>&claims=iban&transaction_data=<...>
-> {"id", "request_uri", "deep_link"}   (QR code or same-phone link)

# 3. After the person confirmed in the wallet: poll from the same browser
GET /oidc.ashx?action=vp-response&id=<id>
-> {"status": "completed",
    "claims": {"iban": "...", "vct": "..."},
    "transaction_data": {"verified": true, "hashes_alg": "sha-256", "hashes": ["..."],
      "transaction_ids": ["8D8AC610-..."],
      "sca": {"authentication_code": "<KB-JWT jti>", "amr": [{"knowledge": "pin_6_or_more_digits"}, {"possession": "key_in_local_native_wscd"}]}}}

OpenAPI (Plattform) · OpenAPI (Plattform)

Was der Server prüft

• Die Payload gegen das TS12-Datenmodell ihres Typs, einschließlich der Regeln im Text: kein Ausführungsdatum in der Vergangenheit, kein Ausführungsdatum zusammen mit einer Wiederholung, ein Mandatstext, wenn keine Zahlung enthalten ist, ISO-4217-Währung, nur https-Links, keine versteckten Textrichtungszeichen.
• credential_ids nennen die Zahlungskarten-Abfrage derselben Anfrage; verwendet wird nur sha-256.
• Das KB-JWT ist mit dem an die Karte gebundenen Schlüssel signiert, und seine transaction_data_hashes sind die SHA-256-Hashes genau der gesendeten Einträge – nicht mehr und nicht weniger.
• jti wird nur einmal akzeptiert (auch im Cluster) und wird zum Authentifizierungscode; amr nennt mindestens zwei verschiedene Faktorkategorien (Wissen, Besitz, Inhärenz) mit den Werten aus TS12; response_mode entspricht dem der Anfrage.
• Die Karte selbst: Signatur des Ausstellers, Vertrauenskette, Sperrstatus und der angefragte Typ, genau wie bei jeder Vorlage aus der Wallet.
• Eine Zahlungsbestätigung entsteht nie aus einer Sitzung mit abgeschwächten Prüfungen oder aus einer Karte, deren Ausstellerkette nicht geprüft werden konnte; die Karte muss als SD-JWT VC kommen.
• Anfragen ohne Transaktionsdaten sind von keiner dieser Prüfungen betroffen.

Ausprobieren

Die Testseite spielt die Bank oder den Händler: Transaktionstyp wählen, mit der Wallet bestätigen und den erwarteten Hash, den Authentifizierungscode und die Faktoren sehen. Auf phone.codeb.io lässt sich eine Test-Zahlungskarte (Typ https://phone.codeb.io/vc/sca-test-account/1.0) in eine Wallet aufnehmen; sie ist kein Bankkonto, und es fließt kein Geld.

Datenschutz von Anfang an

• Die Wallet gibt nur die angefragten Kartenattribute heraus; die Transaktionsdetails bleiben zwischen Ihrer Anfrage und der Bestätigung der Person.
• Eine Zahlungsbestätigung meldet niemanden an, legt kein Konto an und speichert keine Identitätsdaten auf dem Server.
• Das Ergebnis geht nur an den Browser, der die Anfrage gestartet hat.
• Das Protokoll hält fest, dass eine Bestätigung stattfand und welche Prüfungen bestanden wurden, nicht Beträge oder Empfänger.
• Läuft auf Ihrem eigenen CodeB-Mandanten in der EU, ohne Auftragsverarbeiter Dritter.

Ehrliche Grenzen

• Die Person braucht eine Wallet, die TS12 umsetzt – die Transaktion anzeigt und die Hashes, jti und amr in ihre Antwort aufnimmt. Eine Wallet ohne TS12-Unterstützung lehnt die Anfrage ab.
• TS12 v1.0.1 gilt für SD-JWT VC; Vorlagen in anderen Formaten werden für Transaktionsdaten nicht akzeptiert.
• Die Anfrage ist signiert, aber noch nicht verschlüsselt (TS12 empfiehlt Verschlüsselung für Anfragen mit personenbezogenen Daten).
• CodeB liefert das Authentifizierungsergebnis. Die Ausführung der Zahlung über ein Zahlungsnetz bleibt bei Ihrer Bank oder Ihrem Zahlungsdienst; CodeB beansprucht keine PSD2-Zertifizierung.
• Die Testkarte auf phone.codeb.io ist nur zum Testen. Echte Zahlungskarten (SCA-Attestations) stellt die Bank der Person aus.

Häufige Fragen