Zielbild: Scoped Mandate auf Basis von ARF, PaSO und SPAA

Öffentliche Fassung, Stand 15.10.2026. Beschreibt, wohin der Proof of Concept führt: ein Agenteneinkauf, der vollständig auf dem europäischen Vertrauensrahmen steht. Was davon heute schon läuft, steht am Ende.

Die Idee in einem Absatz

Ein Kunde erteilt seiner Bank einmal ein begrenztes Mandat: so viel je Einkauf, so viel insgesamt, so lange, bei diesen Händlern, für diese Warengruppen. Die Freigabe ist eine starke Kundenauthentifizierung in der EUDI-Wallet. Danach kauft ein KI-Agent im Namen des Kunden ein. Bei jedem Einkauf prüfen zwei Parteien unabhängig voneinander: der Händler die Waren, die Bank das Geld. Die Wallet entscheidet nichts über Zahlungen, der Agent auch nicht. Jede Ablehnung nennt Partei und Grund, der Widerruf wirkt sofort.

Rollen nach dem Architecture Reference Framework (ARF)

Das ARF der EU-Kommission beschreibt, wer in der EUDI-Wallet-Welt welche Rolle spielt. Scoped Mandate besetzt diese Rollen so:

ARF-Rolle Im Scoped Mandate Was sie tut
Wallet User Kunde erteilt und widerruft das Mandat
Wallet Unit EUDIPal auf dem iPhone hält Credentials, führt die Präsentationen aus, zeigt an
Wallet Provider Betreiber der Wallet stellt die Wallet Unit bereit, Wallet Unit Attestation
Attestation Provider, (Q)EAA Sparkasse als Aussteller stellt dem Kunden das SCA-Credential aus (SD-JWT VC)
Wallet-Relying Party, Verifier Sparkasse als Bank nimmt die Mandatsfreigabe als Präsentation entgegen und prüft sie
Wallet-Relying Party, Verifier Händler prüft Mandat und Agent-Identität beim Einkauf
Attestation Provider für juristische Personen Betreiber des Agenten mit European Business Wallet (EBW) stellt dem Agenten sein Identitäts-Credential aus
Holder, zweiter Schlüssel in der Wallet Unit Agent eigener Schlüssel im Secure Enclave, eigenes Credential, signiert Zahlungsaufträge
Trusted Lists EU-Vertrauenslisten Anker für Aussteller und Relying Parties, Statuslisten für Widerruf

Zwei Dinge sind bewusst so: Die Bank ist gleichzeitig Aussteller des SCA-Credentials und Verifier der Mandatsfreigabe, denn sie hält das Mandat. Und der Agent ist keine eigene Wallet, sondern ein zweiter Holder-Schlüssel in derselben Wallet Unit, mit einem Credential, das der Betreiber ausstellt.

Protokolle und Formate

Zweck Standard Einsatz
Credentials ausstellen OpenID for Verifiable Credential Issuance (OpenID4VCI) SCA-Credential an den Kunden, Agent-Credential an den Agenten
Credentials vorzeigen OpenID for Verifiable Presentations (OpenID4VP) mit DCQL Mandatsfreigabe an die Bank, Mandat und Agent-Identität an den Händler
Credential-Format SD-JWT VC mit Key Binding (KB-JWT) selektive Offenlegung, Besitznachweis mit Nonce und Audience
Interoperabilitätsprofil HAIP (High Assurance Interoperability Profile) signierte Requests mit x5c, verschlüsselte Antworten, Vertrauensanker
Starke Kundenauthentifizierung PaSO (Payments and SCA for OpenID) Mandat als transaction_data, Hash im KB-JWT, die PaSO-SCA-Claims
Mandatsschema SPAA Dynamic Recurring Payment (SEPA Payment Account Access) das bankgehaltene, scope-begrenzte Mandat
Settlement SEPA Instant Credit Transfer (SCT Inst) jede Zahlung unter dem Mandat
Identität des Betreibers European Business Wallet (EBW), eIDAS-Siegel Legal Person Identification, Siegel über das Agent-Credential

Der Ablauf im Zielbild

A · Agent registrieren (einmalig). Der Agent erzeugt sein Schlüsselpaar im Secure Enclave. Der Betreiber stellt ihm per OpenID4VCI ein Credential aus, gesiegelt aus der EBW: Agent-ID, Betreiber mit Registernummer, Rolle, Gültigkeit, Schlüssel als Besitznachweis.

B · Mandat erteilen (eine SCA). Der Kunde erteilt ein Mandat, das bei der Bank liegt und aus zwei Teilen besteht. Der Payment-Teil ist offen: Limits, Gültigkeit, erlaubte Händler. Der Checkout-Teil ist versiegelt: Warengruppen und Altersfreigabe, vom Kunden signiert und mit einem Wallet-Schlüssel verschlüsselt. Die Bank schickt einen OpenID4VP-Request im PaSO-Profil mit dem Payment-Teil als transaction_data; darin steht der Hash des Checkout-Teils, nicht sein Inhalt. Die Wallet zeigt dem Kunden beides, der Kunde bestätigt per Face ID, die Wallet präsentiert das SCA-Credential mit KB-JWT und signiert mit demselben Schlüssel den Checkout-Teil. Die Bank prüft Credential, Key Binding, Hash und die PaSO-Claims, legt je Mandat eine Zeile an (Hash, Limits, Verbrauch, Status) und verwahrt den versiegelten Checkout-Teil als Notar: beglaubigt, nicht gelesen. Was gekauft werden darf, erfährt sie nicht.

C · Einkaufen (ohne Rückfrage). Der Agent legt dem Händler den vom Kunden signierten, geöffneten Checkout-Teil vor. Der Händler prüft die Signatur und den Warenkorb gegen die Warengruppen und bestätigt mit einer Attestation, die den Hash des Checkout-Teils und des Warenkorbs trägt. Der Agent reicht der Bank einen Zahlungsauftrag ein, der das Mandat und die Attestation referenziert. Die Bank prüft Händler, Limits, Gültigkeit und die Händlersignatur, dann zahlt sie per SCT Inst. Ob der Agent sich zusätzlich mit einem Betreiber-Credential ausweisen muss, entscheidet die Bank als Policy; für die Zurechnung zum Kunden reichen die beiden Signaturen des Kunden.

D · Nein sagen und widerrufen. Passt die Ware nicht, lehnt der Händler ab. Passt das Geld nicht, lehnt die Bank ab. Jede Ablehnung nennt Partei und Grund, nichts wird bezahlt. Der Kunde widerruft jederzeit an einem Ort, bei der Bank in der App oder in der S-App: Beide Teile erlöschen, die Bank lehnt jede weitere Zahlung ab, Agent und Händler sehen den Status. Als Sofortmaßnahme kann die Wallet den Agenten zusätzlich lokal anhalten. Ein Agent, den der Kunde nicht stoppen kann, gehört nicht zu Endkunden.

Was die Gewaltenteilung garantiert

Partei Sieht Entscheidet über
Kunde, Wallet alles, auf dem eigenen Gerät die eine Freigabe, den Widerruf
Agent, KI Wunsch, Korb, Preise, Checkout-Teil nichts über Geld
Händler Warenkorb, Checkout-Teil mit Warengruppen Warengruppen, Altersfreigabe
Bank Payment-Teil: Betrag, Limits, Händler, Hashes; Checkout-Teil nur versiegelt Limits, Händler, Gültigkeit, Widerruf

Die Bank sieht nie den Warenkorb, der Händler nie die Limits, die KI nie das Konto. Die Intelligenz ist austauschbar, die Sicherheit liegt im Mandat und in den Prüfungen von Bank und Händler.

Was heute schon läuft und was Zielbild ist

Baustein Heute im PoC Zielbild
Ausstellung des SCA-Credentials per OpenID4VCI läuft, die Bank ist selbst Issuer: Credential nur aus der angemeldeten Online-Banking-Sitzung, eigene Vertrauenswurzel für Issuer und Verifier, Widerruf per Statusliste. Demo-Issuer und eigener Issuer laufen parallel, der Verifier akzeptiert beide über Wurzel bzw. Vertrauensliste gleich, mit qualifizierten Zertifikaten eines Vertrauensdiensteanbieters
Einzelzahlung per OpenID4VP im PaSO-Profil läuft gleich
Mandat als eigener Transaction-Data-Typ mit Schema und Hash-Regel läuft gleich, Inhalt wird auf Zahlungsdaten plus Checkout-Hash reduziert
Was die Bank vom Mandat liest Payment Scope und Fach-Scope nur den Payment-Teil; den Checkout-Teil verwahrt sie versiegelt als Notar (Design-Revision, in Arbeit)
Mandatsfreigabe Geräte-SCA, Nachweis an die Bank-API OpenID4VP im PaSO-Profil, Bank als Verifier
Agent-Identität von der App selbst ausgestellt, von der Bank auf Konsistenz geprüft optional nach Policy der Bank; wenn gewünscht vom Betreiber per OpenID4VCI ausgestellt, aus der EBW gesiegelt, per OpenID4VP präsentiert
Händlerprüfung Warengruppen gegen die vom Agenten gemeldeten Grenzen Warengruppen gegen den vom Kunden signierten Checkout-Teil
Vertrauensanker Bank-Seite: Issuer und Verifier unter einer eigenen Wurzel, Verifier prüft Kette und Statusliste. Wallet-Seite: Ketten werden akzeptiert, Wurzel noch nicht hinterlegt EU-Vertrauenslisten in Wallet und Verifier
Mandatsschema und Settlement SPAA DRP, SCT Inst, simuliert gleich, an echte Systeme angebunden

Bank und Händler sind im PoC Mocks mit stabilen, dokumentierten Schnittstellen. Der Weg vom Heute zum Zielbild tauscht die Mocks und die Transportprotokolle, nicht die Schnittstellenverträge und nicht die Rollenverteilung.

Weiterlesen