Zusammenfassung

  • VCAP-02 wurde am 4. September als individuelles Internet-Draft angekündigt; es besitzt weder IETF-Billigung noch formalen Standardstatus, RFC-Stream oder verantwortlichen Area Director.
  • Ein neuer Abschnitt erkennt an, dass ein Marktplatz durch die Prüferauswahl Abrechnungsergebnisse wirksam kontrolliert, und verlangt Aufzeichnungen zu Schlüsseln, Fähigkeiten, Streitwegen und Änderungen.
  • Dennoch stammt service_delivery vom Anbieter und darf auto_approve enthalten: Die automatische Prüfung wird übersprungen, der Anbieter bestätigt sich selbst.
  • Der Text bestimmt weder den Annehmenden dieser Ausnahme noch Vertragsgrundlage, Grenzwerte, Restprüfungen, callback-Unterzeichner, Ablauf, Widerruf oder Einspruch.
  • Vor dem Geldfluss braucht es einen Prüfungsverzichtsbeleg, der Vorschlag, Annahmebefugnis, Vertragsgrund, Umfang, Grenzen, Geltung, Unterzeichner, Gegenbelege, Streitweg und Endzustand verbindet.

Für den normalen Prüfpfad ist Macht erstmals sichtbar

Die IETF-Ankündigung belegt ein begrenztes Ereignis: Am 4. September wurde ein dreißigseitiges Internet-Draft von Ben Stone verfügbar. Der Datatracker-Eintrag zieht die institutionelle Grenze. Es handelt sich um eine aktive individuelle Einreichung. Jeder kann ein I-D einreichen; dieses Dokument wird von der IETF nicht gebilligt und hat in ihrem Standardisierungsprozess keine formale Stellung, keinen RFC-Stream und keinen verantwortlichen Area Director. „Informational“ ist ein Ziel im Entwurfskopf, kein erlangter Status.

Innerhalb dieser Grenze beschreibt Revision 02 eine Maschine mit finanzieller Wirkung. Auftraggeber und Anbieter einigen sich auf Leistung und Preis. Ein Marktplatz hält Geld zurück. Der Anbieter liefert, ein Prüfer untersucht das Ergebnis und sendet verification_callback. passed=true führt zu VERIFIED und Freigabe, false zu FAILED und Erstattung. Der Entwurf bezeichnet den callback selbst als wichtigste Nachricht, weil er die Abrechnung auslöst.

Der offizielle Vergleich zeigt die zentrale Ergänzung gegenüber Revision 01: „Verifier Accountability“. Der Text sagt ausdrücklich, dass der Marktplatz Abrechnungsergebnisse effektiv kontrolliert, wenn er Prüfer auswählt. Vor der Annahme eines Ergebnisses muss er den Ed25519-Schlüssel oder die Methode registrieren und als vertrauenswürdig behandeln, die angegebenen Fähigkeiten erfassen und einen Eskalationsweg für angefochtene Resultate definieren. Registrierung, Schlüsselwechsel und Abmeldung müssen mit Zeitstempel bei den Abrechnungsunterlagen bleiben.

Kontrolliert der Marktbetreiber zugleich den Prüfer, sollen Auftraggeber und Anbieter einen gemeinsam bestimmten Dritten einsetzen können. Außerdem soll der Marktplatz veröffentlichen, welche Prüfertypen für welche Dienste gelten, wie Interessenkonflikte behandelt werden und wie Einsprüche weitergehen. Gemeinsame Auswahl und Veröffentlichung sind SHOULD; Schlüssel-, Fähigkeits-, Streit- und Änderungsaufzeichnungen sind MUST.

Der Entwurf lässt damit sinnvolle lokale Unterschiede zu. Eine kleine Routineleistung braucht nicht dasselbe Verfahren wie ein teures, subjektives Werk. Aber gerade weil die Auswahlmacht benannt wird, fällt die symmetrische Leerstelle auf: Wer darf auswählen, dass keine automatische Prüfung stattfindet?

Der Begünstigte liefert den Ausnahmeschalter mit

Der Anbieter sendet service_delivery, sobald er Erfüllung behauptet. Die Nachricht enthält Status, Beschreibung, Artefakte und Prüfungshinweise wie URL, Selektor, erwarteten Inhalt oder Fingerabdruckänderung. Im selben Objekt steht auto_approve. Bei true soll die automatische Prüfung entfallen; der Anbieter bestätigt sich selbst.

Das verlinkte service-delivery JSON Schema formuliert den Ursprung noch deutlicher. Hinweise des Anbieters dürfen diejenigen des Auftraggebers „überschreiben oder ergänzen“. Der Standardwert ist false. Ein Standardwert ist jedoch keine Vollmacht: Er regelt den fehlenden Wert, nicht die Wirksamkeit eines true, das der Zahlungsempfänger sendet.

In jeder fixierten Fassung -00, -01 und -02 erscheint auto_approve genau zweimal, im Nachrichtenbeispiel und in der Hinweistabelle. Es fehlt eine Verarbeitungsregel für berechtigten Vorschlag, annehmende Instanz, Vertragsklausel, Wert- oder Risikogrenze, verbleibende Kontrollen, Ablauf, Widerruf, Konflikt und Entscheidungsprotokoll.

Soll ein Markt ein nicht erkanntes true ignorieren, zurückweisen, die Mittel HELD lassen, beim Auftraggeber nachfragen oder einen Menschen einschalten? Jede Antwort kann eine vernünftige lokale Regel sein. Keine lässt sich als gemeinsame interoperable Regel aus dem heutigen Text ableiten.

Aus dieser Lücke darf kein Vorfall erfunden werden. Die Quellen zeigen nicht, dass eine konkrete Implementierung das Feld verarbeitet, dass ein Anbieter eine Auszahlung erzwang oder dass Missbrauch entstand. Belegt ist nur, dass der Entwurf den vollständigen Entscheidungsweg nicht vorgibt.

Zwischen Verzicht und callback fehlt die Zuständigkeit

Ein normaler callback enthält Prüf-ID, passed, Beweishash, Signatur, Prüfschlüssel-ID, Aktionsprotokoll und Abschlusszeit. Die Abrechnung übernimmt ID, Hash und Signatur. Wer erzeugt diese Nachricht, wenn die automatische Prüfung bewusst nicht ausgeführt wurde?

Signiert der Anbieter, wird die Selbstbehauptung des Begünstigten zum eigenen Urteil. Signiert der Marktplatz, bestätigt er eine Risikoannahme und keine unabhängige Beobachtung der Leistung. Signiert ein Mensch, handelt es sich faktisch um eine manuelle Prüfung, deren Rolle benannt werden kann. Der Entwurf entscheidet sich für keine Semantik und erklärt nicht, wie eine absichtlich unterlassene Handlung in einem Aktionsprotokoll erscheint.

Kryptografie verteilt keine Befugnisse. VCAP-02 bildet SHA-256 über ein kanonisches Beweispaket und signiert mit Ed25519 Prüf-, Verhandlungs- und Escrow-Bezüge, Ergebnis, Hash, Schlüsselkennung und Zeit. RFC 8032 erlaubt die Prüfung dieser Signatur mit dem öffentlichen Schlüssel. VCAP begrenzt die Aussage korrekt: Der Hash zeigt Inhaltsintegrität, die Signatur die Herkunft von einem autorisierten Prüfer. Beides beweist weder den Verzicht des Auftraggebers noch dessen Vertragsgrundlage.

Atomarität löst ein anderes Problem. Compare-and-swap verhindert, dass derselbe Betrag freigegeben und erstattet wird. Idempotenz verhindert eine zweite Abrechnung durch Wiederholung. Genau ein Endzustand kann technisch sauber sein, obwohl die Ermächtigung des Ausnahmewegs ungeklärt bleibt.

Der Timeout-Pfad zeigt, wie eine Ausnahme vollständig aussehen kann. Nach standardmäßig 1.800 Sekunden bleiben die Mittel HELD. Ein manueller Prüffall soll entstehen, und ein Mensch muss abschließend entscheiden. Er sendet einen üblichen callback mit einer Aktionszeile, Hash und Signatur. Entscheider, Nachricht und Weg bleiben rekonstruierbar. Für auto_approve fehlt dieses Gegenstück.

Selbstbestätigung kann geschäftlich sinnvoll sein. Stammparteien können bei geringem Wert Geschwindigkeit über zusätzliche Prüfung stellen. Doch eine vorher vereinbarte Ausnahme ist nicht dasselbe wie ein true, das der Begünstigte bei Lieferung mitschickt.

Auch die verlinkten ausführbaren Artefakte driften

Die öffentlichen Schemas waren zum Stichtag nicht synchron. Das verification-callback Schema verlangt weiterhin einen hexadezimalen HMAC-SHA256, akzeptiert nur vcap_version 1.0 und enthält keine verifier_key_id. Revision 02 verlangt Ed25519, Base64 und die Schlüsselkennung. Die Repository-Historie zeigt, dass die verlinkten Schemas nicht zusammen mit der September-Einreichung aktualisiert wurden.

Das beweist keinen Produktionsfehler. Es zeigt, dass ein Leser der neuen Prosa und ein Validator des verlinkten Schemas verschiedene Verträge erhalten. Bleibt die Verzichtsvollmacht ebenfalls außerhalb prüfbarer Artefakte, können zwei Parser dasselbe JSON akzeptieren und dennoch gegensätzliche Abrechnungen erzeugen.

Die neue Fassung korrigiert zudem die Beziehung zu AP2. AP2 behandelt Mandate, Rollen und Zahlungsbelege; VCAP-02 nimmt nicht länger an, AP2 liefere Escrow-, Einzugs-, Erstattungs- oder Abrechnungszustände. Die fehlende Zuständigkeit für auto_approve kann also nicht stillschweigend an das vorgelagerte Protokoll delegiert werden.

Ein Prüfungsverzichtsbeleg vor der Abrechnung

Eine schmale gemeinsame Struktur genügt. Der Beleg nennt Transaktion, Verhandlung und Escrow; Revisionen und Hashes von Text und Schemas; den Anbieter als Vorschlagenden; die Vertragsklausel; annehmende Akteure bei Auftraggeber und Markt; die verdrängte Prüferauswahl; erlassene und verbleibende Kriterien; Grund; Wert- und Risikolimit; Beginn, Ablauf und Widerruf; callback-Modus und Unterzeichner; Gegenbelege; Streitweg; sowie den Endzustand der Mittel.

Dieser Beleg muss vor der Abrechnung entstehen. Lässt sich die Klausel oder Annahmebefugnis nicht auflösen, weist der Markt den Hinweis zurück oder belässt HELD. Er leitet keinen neuen Prüfungsverzicht aus einer allgemeinen früheren Vertragsannahme ab.

Die lokale Wahl bleibt erhalten. Parteien dürfen je nach Leistung Selbstbestätigung, unabhängige oder menschliche Prüfung wählen. Gemeinsam wird nur das Minimum: Wer durfte die Ausnahme wählen, wofür, wie lange und mit welcher Folge? Das macht lokale Freiheit überprüfbar, ohne eine globale Prüfinstanz zu schaffen.

Quellen

  1. IETF-Ankündigung von VCAP Revision 02
  2. Status im IETF Datatracker
  3. VCAP Revision 02
  4. VCAP Revision 01
  5. Offizieller Vergleich von 01 und 02
  6. service_delivery JSON Schema
  7. verification_callback JSON Schema
  8. Historie des VCAP-Repositorys
  9. RFC 8032 — EdDSA
  10. Spezifikation des Google Agent Payments Protocol
  11. Heng Lu über Running-Code-Primat
  12. Heng Lu über minimale gemeinsame Regeln und lokale Wahl