GoDaddy, Infoblox, Google und Cloudflare demonstrieren gemeinsam mit Singapurs Infocomm Media Development Authority (IMDA) bei GovWare 2026 die offene Referenzarchitektur Chain of Trust. Die Veranstaltung läuft vom 13. bis 15. Oktober 2026. Open Agent Commerce nennt diesen Zeitraum für GovWare 2026.
Der Test simuliert einen Flugkauf von Madrid nach Singapur. Stripe lief im Testmodus; echtes Geld floss nicht. Die technische Fallstudie von Open Agent Commerce beschreibt Chain of Trust als frühe Referenzarchitektur, die zeigen soll, wie unabhängig betriebene Agenten Identität und Zahlungsbefugnis prüfen können.
Die vier Agenten und ihre Aufgaben
Im Test übernehmen vier Agenten getrennte Rollen: Käufer, Verkäufer, Freigabedienst und unabhängiger Verifizierer. Sie laufen über drei Cloud-Anbieter und vier Domains verteilt. AWS hostet den Käuferagenten, Cloudflare den Verkäuferagenten; Freigabedienst und Verifizierer laufen auf Google Cloud.
Der Käuferagent sucht den Verkäufer und stößt den Kauf an. Der Verkäufer veröffentlicht sein Geschäftsprofil und signierte Preisangebote. Der Freigabedienst stellt die Mandate aus, während der Verifizierer die veröffentlichten Datensätze und die Mandatskette nachprüft.
Vom Auffinden des Verkäufers bis zur Prüfung
Der Ablauf beginnt mit einer Passkey-Anmeldung und der Suche nach einem Verkäufer über DNS. Danach prüft der Käuferagent den Verkäufer und sammelt signierte Angebote. Nach der Freigabe durch die Person sendet er eine signierte Kaufanfrage. Der Verkäufer prüft diese, bevor der Zahlungsvorgang im Stripe-Testmodus ausgeführt wird. Signierte Belege und Ledger-Prüfpunkte fließen anschließend in die unabhängige Verifikation ein.
Die Architektur kombiniert dabei verschiedene Aufgaben: DNS, DNSSEC und DANE verknüpfen die Identität eines Dienstes mit seiner Domain; A2A und MCP unterstützen die Kommunikation zwischen Agenten und den Zugriff auf Werkzeuge. UCP transportiert in der Demonstration das Geschäftsprofil und die Checkout-Anfrage. Einige Bausteine haben noch Entwurfsstatus: Die Fallstudie bezeichnet DNS-AID und ANS als IETF-Internet-Drafts und ARD als Community-Spezifikation.
Wie die menschliche Freigabe die Zahlungsbefugnis begrenzt
Die Person bestätigt den Kauf per Passkey. Ein unabhängiger Freigabedienst stellt danach zwei signierte AP2-Mandate aus: Das Checkout-Mandat gilt für einen bestimmten Verkäufer und Checkout, das Zahlungsmandat nennt einen Zahlungsempfänger und einen Betrag. Beide Mandate sind zeitlich begrenzt und an den Schlüssel des Käuferagenten gebunden. Der Käuferagent kann sie nicht selbst ausstellen.
Die Person kann den Agenten stoppen oder eine Freigabe widerrufen. Vor der Zahlung prüft der Verkäufer außerdem den aktuellen Status des Mandats beim Freigabedienst. Auch der Betreiber kann einen Agentenschlüssel zurückziehen oder dessen DNS-Eintrag entfernen.
Was Prüfungen und Ledger festhalten
Der Käuferagent führte 14 Prüfungen am Verkäufer durch, der Verkäufer vor der Zahlung zehn weitere. Die Fallstudie berichtet, dass die getesteten gefälschten und manipulierten Anfragen abgewiesen wurden; keine führte zu einer Zahlung.
Jeder Teilnehmer führte ein eigenes, durch Hashes verkettetes Ledger. Signierte Prüfpunkte wurden für die Demonstration in einem öffentlichen SCITT-Transparenzprotokoll registriert. Die öffentlichen Ledger dienten der Veranschaulichung; für den kommerziellen Einsatz sieht die Fallstudie private Ledger vor, auf die ausgewählte Verifizierer Zugriff erhalten. Ein Transparenzprotokoll kann belegen, dass ein Datensatz zu einem bestimmten Zeitpunkt unverändert vorlag. Es bestätigt nicht, dass sein Inhalt wahr ist.
