UCP Mandate Evaluation — Lifecycle-Profil
com.merchantstamp.mandate-evaluation
Diese Seite ist die kanonische Referenz für das Lifecycle-Profil mandate-evaluation, das MerchantStamp für die Checkout-Capability des Universal Commerce Protocol (UCP) vorschlägt. Sie legt fest, was ein Händler tut, wenn die TTL eines AP2-Mandats während des Checkout-Abschlusses abläuft. UCPs Beitrag sind die Lifecycle-Semantik und der Auswertungspunkt — kein neues Belegformat. Das Ergebnis wird über die bestehende AP2/FIDO-Belegkonstruktion ausgedrückt.
Status & Namespace
Vorgeschlagene Erweiterung der UCP-Checkout-Capability, veröffentlicht unter dem Hersteller-Namespace com.merchantstamp.mandate-evaluation gemäß UCPs Vendor-Namespace-First-Regel, ausstehende Promotion in den Core. Sie definiert ausschließlich Lifecycle-Semantik und verwendet die AP2/FIDO-Belegkonstruktion wieder — sie führt keine UCP-eigene Belegfamilie ein. Normative Schlüsselwörter folgen RFC 2119 / RFC 8174. Der Vorschlag löst UCP-Issue #512 und wurde nach dem Review-Feedback in Issue #515 verfeinert.
Die geschlossene Lücke
Der Checkout-Lifecycle hat einen Verarbeitungszustand — complete_in_progress —, der erreicht wird, nachdem ein Händler Complete Checkout akzeptiert und bevor die Bestellung completed erreicht. Wenn die Mandats-TTL abläuft, während die Session bereits in complete_in_progress ist, definiert die aktuelle Spezifikation nicht, was passiert. AP2/UCP Mandates besagt nur, dass der Händler die Expiry bei der complete-Anfrage prüft, und mandate_expired bedeutet nur, dass der exp-Zeitstempel überschritten ist. Keiner der beiden klärt den In-Flight-Fall. Das ist eine Checkout-Zustandsautomaten-Frage, und genau die spezifiziert dieses Profil.
Autorisierung vs. Liveness
Das Profil trennt zwei Eigenschaften, die üblicherweise unter „TTL-Gültigkeit“ vermischt werden:
Autorisierung
Hat der Käufer diese Belastung erlaubt? Festgelegt in dem Moment, in dem der Händler Complete Checkout gegen ein zu diesem Zeitpunkt gültiges Mandat akzeptiert. Eine vom Käufer nicht verursachte Verarbeitungsverzögerung hebt sie nicht auf. Die Unwiderruflichkeit nach Art. 80 PSD2 ist die Grenze.
Liveness
Liegt die Ermächtigung gerade jetzt in ihrem Fenster? Liveness steuert, ob eine Zahlung in die Verarbeitung eintreten DARF; sie bestimmt nicht, ob bereits zugelassene Arbeit autorisiert bleibt. Die TTL ist eine vorab vereinbarte Grenze dafür, wann die Ermächtigung ausgeübt werden darf, kein Live-Widerrufssignal.
Das Modell
Die Mandatsgültigkeit genau einmal am Verwendungspunkt (Eingang von Complete Checkout) gegen bindende Transaktionsdaten prüfen und die Autorisierung dort einfrieren. Ein zu diesem Zeitpunkt gültiges Mandat läuft unabhängig von späterem Ablauf bis zu einem terminalen AP2-Beleg; ein zu diesem Zeitpunkt bereits abgelaufenes Mandat tritt nie in die Verarbeitung ein. Das spiegelt wider, wie Checkout bereits die Eligibility Verification at Completion behandelt: eine Eigenschaft, die einmal, an einem definierten Punkt, auf bindenden Daten aufgelöst wird. Es wird kein neuer Lifecycle-Status eingeführt — die Erweiterung beschränkt nur, welcher Übergang aus ready_for_complete genommen wird.
Zwei Ergebnisse
Der Händler MUSS die Autorisierung für die Session einfrieren, MUSS die Auswertung als verifizierbare Attestierung aufzeichnen, DARF in complete_in_progress übergehen und MUSS bis zu einem terminalen Zustand laufen. Späterer Ablauf DARF NICHT die Verarbeitung abbrechen oder das Settlement-Fenster verkürzen.
Die Session DARF NICHT in complete_in_progress eintreten. Sie MUSS canceled mit einer mandate_expired-Meldung terminieren und MUSS den Ablauf als terminales Artefakt offenlegen. Invariante: mandate_expired DARF NICHT gemeldet werden, sobald eine Session in complete_in_progress eingetreten ist.
Belege verwenden AP2/FIDO wieder
Beide Ergebnisse werden über die bestehende AP2-Checkout/Payment-Belegkonstruktion (oder ein minimales AP2-konformes Profil davon) ausgedrückt — keine separate UCP-Belegfamilie. UCPs einzige normative Anforderung hier ist Bindung und gegenseitiger Ausschluss: die aufgezeichnete Auswertung (positiver Fall) und das terminale Ablauf-Ergebnis (Stornierungsfall) sind dieselbe Beweisform über einen Verifikationspfad, unterschieden durch Typ/Grund des Belegs; ein Verifizierer MUSS beide über die Mandatsreferenz + checkout_id an denselben Flow binden können; und für eine checkout_id DARF ein Händler NICHT sowohl eine positive aufgezeichnete Auswertung als auch ein terminales Ablauf-/Stornierungsartefakt ausgeben. Signierung und Verifikation verwenden die AP2/UCP-Beleg- und Signaturkonstruktion wieder (ES256 empfohlen, JCS-RFC-8785-Kanonisierung, detached JWS) statt eines UCP-spezifischen Mechanismus.
Capability-Profil
Der Händler kündigt seine Unterstützung an, damit Plattformen ein Mandat vor dem Abschluss erneuern, statt gegen die Grenze zu rennen:
mandate_evaluationBoolean — ob der Händler die Mandatsgültigkeit am Verwendungspunkt gemäß diesem Profil auswertet.min_remaining_ttlISO-8601-Dauer — die minimale Rest-TTL, die ein Mandat bei Complete Checkout tragen muss, damit der Händler es zulässt.Beleg-/SignaturprofilDas AP2-Beleg- und Signaturprofil, das der Händler ausgibt, damit eine Plattform weiß, welche Beweisform zu erwarten ist.Wo MerchantStamp passt
MerchantStamp implementiert einen UCP-Händlerserver für Long-Tail-Händler. Im Agentic-Commerce-Stack übernimmt MCP die Agent-zu-Tool-Bindung, AP2/FIDO liefert die kryptografische Autorität und den Beweis-Beleg, und UCP trägt den Commerce-Lifecycle. Dieses Profil liegt genau auf der UCP-Lifecycle-Ebene: es spezifiziert einen Zustandsautomaten-Übergang und verwendet AP2/FIDO für den Beleg wieder — bewusst ohne Überschneidung mit den Ebenen darüber und darunter.