Summary

  • Der individuelle Internet-Draft Selo vom 31. Oktober 2026 skizziert Zugangsvereinbarungen zwischen Unternehmen, die deren Agenten aushandeln. Er ist weder verabschiedetes Protokoll noch IETF-Standard.
  • Ein isolierter, deterministischer Prüfer kontrolliert vor der Signatur die vom Eigentümer unterzeichneten Grenzen. Erst nach beiderseitiger Unterschrift und Tests gibt es produktive Zugangsdaten.
  • Neue Zahlungsdaten erfordern eine neu signierte Vereinbarung, Freigabe durch eine Person mit Finanzfunktion, direkte Mitteilung vorbei an beiden Agenten und Bestätigung durch den Zahler vor der ersten Zahlung.

Der gefährlichste Änderungsantrag sieht harmlos aus

Eine Lieferantenadresse im System zu ändern, ist Routine. Eine Lieferanten-Bankverbindung zu ändern, ist eine Anweisung darüber, wohin der nächste Geldbetrag fließt. Selo behandelt diese beiden Felder nicht gleich. Der Agent darf über Bestellungen, Rechnungen und Schnittstellen verhandeln. Für neue Zahlungsdaten reicht sein Mandat ausdrücklich nicht.

Eine Person mit Finanzfunktion muss eine neue Version der Vereinbarung billigen. Die Menschen auf der zahlenden Seite bekommen eine Nachricht über einen Weg, der beide Agenten umgeht. Bis zum Ablauf einer Wartefrist gelten die alten Daten; jede Seite kann abbrechen. Vor der ersten Zahlung an das neue Konto bestätigt ein Mensch auf der Zahlerseite die Änderung. Die im Text genannten 72 Stunden sind ein Beispiel für die Wartezeit, keine fest vorgeschriebene Dauer.

Selo baut sonst auf Automatisierung. Agenten verifizieren ihre Zugehörigkeit zu Rechtsträgern und handeln typisierte Bedingungen aus. Ein separater deterministischer Prüfer entscheidet, ob eine Vereinbarung in die signierten Grenzen des Eigentümers passt. Rechtlich verpflichten sich die Unternehmen, nicht ihre austauschbaren Agenten. Nach den Unterschriften testen beide Laufzeitumgebungen die Verbindung vollständig und bestätigen das Ergebnis, bevor produktive Berechtigungen entstehen.

Das Gateway des Anbieters prüft bei jedem Aufruf ein kurzlebiges Token, das an Vereinbarung und Schlüssel des Aufrufers gebunden ist. Hinzu kommen Status, Version, erlaubter Endpunkt, Operation, Felder und Grenzen. Die eigenen Plattformzugänge des Anbieters bleiben in seinem Tresor. Technische Zugangskontrolle ist damit greifbar. Ob das neue Konto wirklich dem Lieferanten gehört, bleibt eine Entscheidung mit finanzieller Verantwortung.

Der Lieferantenfall ist ein Beispiel im Entwurf, kein belegter Betrugsfall. Selo selbst überweist kein Geld. Die IETF führt das Papier als individuellen Vorschlag ohne formellen Standardstatus; der Autor stellt Architektur und Zuständigkeit für mögliche weitere Arbeit zur Diskussion.

Offizielle Quellen