Das Interoperabilitätsziel
Stellen Sie sich einen Buyer-Agenten vor, der außerhalb Europas läuft und auf einen Merchant-Agenten trifft, der für einen europäischen Händler spricht. Der Buyer-Agent sollte dabei nicht auf Logos, Chat-Texte oder private Zusicherungen vertrauen müssen.
Genau dort setzt ADI an. Der Merchant-Agent kann im Shop des Händlers laufen und weiter A2A sprechen. ADI liefert die unabhängige Vertrauensebene, über die andere Agenten prüfen können, welchem Händler der Agent zugeordnet ist, welche Rolle er hat und ob die Delegation noch gültig ist.
Die vier Dinge, die nicht vermischt werden dürfen
AgentCard ist Discovery: Adresse, Fähigkeiten, Authentisierung und Trust-Verweise.
Trust Profile ist Identitätsbindung: Agent-DID, Operator, Organisation, Veröffentlichungsstatus und Verifikationssignale.
Credentials sind portable Autoritätsnachweise: etwa AP2AgentDelegationCredential, AP2MerchantCredential oder AP2ProductOfferingCredential.
Plattformrechte sind interne Durchsetzung: ADI-Scopes steuern interne APIs, externe Vertrauensbeweise bleiben signierte Claims.
Wie der Verifikationsfluss funktioniert
Ein externer Buyer-Agent prüft einen ADI-Merchant-Agenten
Zuerst wird die A2A-Fläche entdeckt, danach folgt die Trust-Kette mit Profil, Credentials und Statusprüfungen.
sequenceDiagram
participant Foreign as Externer Buyer-Agent
participant Card as Öffentliche AgentCard
participant Trust as ADI Trust-Profil
participant Creds as ADI Credential-Manifest
participant Merchant as Merchant-Agent
participant Pay as Merchant-Payment-Rail
Foreign->>Card: Lade /.well-known/agents/{agentId}/card.json
Card-->>Foreign: A2A-Endpunkt, DID, Auth-Schemes, Trust-Links
Foreign->>Trust: Lade öffentliches Trust-Profil
Trust-->>Foreign: Agent-DID, Händlerbindung, Verifikationsstatus
Foreign->>Creds: Lade Credential-Manifest
Creds-->>Foreign: Signierte Credentials und Verifikations-URLs
Foreign->>Foreign: Prüfe Issuer, DID, Status, Ablauf und Claims
Foreign->>Merchant: Sende AP2/A2A-Anfrage mit Mandatsbezug
Merchant->>Trust: Prüfe Mandat, Katalog, Policy und Credential-Bindung
Trust-->>Merchant: Freigabe oder Ablehnung
Merchant->>Pay: Erzeuge Merchant-Acquiring-Zahlung bei Freigabe Warum OAuth allein nicht reicht
OAuth, OIDC, API-Keys oder JWTs beantworten nur die Transportfrage: Darf dieser Aufrufer diesen Endpunkt benutzen? Sie beweisen nicht, dass der Agent rechtlich oder kommerziell für einen Händler sprechen darf oder dass ein Payment-Mandat gültig ist.
ADI hält diese Schichten bewusst getrennt. Der Merchant-Agent kann OAuth für den Kanal verlangen, aber der Buyer-Agent prüft zusätzlich DID, Trust-Profil, Manifest, Credential-Signaturen, Status und Mandatslage.
Was ein externer Agent konkret prüfen sollte
Die AgentCard muss öffentliche URLs nutzen, nicht Docker-Hostnamen oder localhost.
Die Trust-Chain-Erweiterung muss auf AgentCard, Trust-Profil, Manifest und Verifikationsoberfläche zeigen.
Die Credential-Subjekt-DID muss zur DID in AgentCard und Trust-Profil passen.
Issuer, Status, Ablauf und Proof müssen verifiziert sein, bevor der Merchant-Claim als belastbar gilt.
Für Commerce müssen zusätzlich AP2-Mandate, Merchant-Katalog und Zahlungsregeln für genau diese Transaktion passen.
Das Betriebsmodell von ADI
Damit bleibt ADI offen. ADI-Agenten können außerhalb von ADI kaufen, solange Mandate, Prepaid-Karten und Trust-Prüfungen passen. Merchant-Agenten können Zahlungen über den Merchant-Acquiring-Pfad annehmen.
Das Ergebnis ist keine geschlossene Plattform, sondern eine öffentliche Trust-Schicht, über die unabhängige Agenten Discovery, Verifikation und Transaktionen auf nachvollziehbare Weise verbinden können.