Zusammenfassung

  • AIP verlangt zwei Nachweise: Die Signatur bestätigt den Besitz des vorgelegten Schlüssels; Registrierung oder aufgelöstes DID-Dokument müssen bestätigen, dass dieser Schlüssel an agentDid gebunden ist.
  • Revision 03 weist did:web im Providerbereich und did:opena2a im Ökosystembereich unterschiedlichen Autoritäten zu. Selbstdeklarierter Typ und Zweck sind keine Autorisierung.

Im Prüfprotokoll standen fünf Erfolge: Challenge korrekt, Zeitfenster offen, Nonce neu, Algorithmus unterstützt, Signatur gültig. Trotzdem durfte der Vorgang nicht freigegeben werden. Der öffentliche Schlüssel in der Antwort war nicht derselbe, den das Register dem genannten Agenten zuordnete.

Die Signatur war deshalb nicht falsch. Sie bewies, dass jemand den privaten Gegenpart zum mitgelieferten Schlüssel besaß. Unbewiesen blieb, ob dieser Schlüssel für die behauptete Identität sprechen durfte. Genau zwischen diesen beiden Sätzen verläuft die Vertrauensgrenze von OpenA2A Agent Identity Protocol (AIP) Revision 03.

Die Fassung wurde am 2. Oktober 2026 als aktiver individueller Internet-Draft veröffentlicht und läuft am 3. April 2027 aus. Sie ist weder RFC noch Arbeitsgruppendokument, IETF-Konsens oder Bereitstellungsnachweis. Der Text nennt Standards Track als Ziel der Autoren; ein Ziel ist kein verliehener Status.

Der signierte Kern ist schmal

Der Prüfer erzeugt eine Challenge aus 32 Zufallsbytes, dem behaupteten agentDid, einer 16-Byte-Nonce, issuedAt, expiresAt und issuerDid. Die Zeiten stehen in UTC nach RFC 3339; das Fenster beträgt fünf Minuten.

Signiert wird:

<challenge>|<agentDid>|<nonce>|<issuedAt>|<expiresAt>

Die Antwort bringt zusätzlich publicKey, keyId, signedAt und algorithm mit. Diese vier Felder gehören nicht zur signierten Zeichenfolge. Der beigefügte Schlüssel ist geeignet, Besitz zu prüfen, aber nicht, seine eigene Zuständigkeit zu bescheinigen. Wer ein Schlüsselpaar erzeugen kann, kann eine Nachricht unter diesem eigenen Schlüssel korrekt signieren.

Das erste Ergebnis muss daher „unter vorgelegtem Schlüssel gültig“ heißen. Die Oberfläche darf daraus nicht ohne zweite Quelle „Agent authentifiziert“ machen.

Besitz und Zuordnung

Regel eins prüft die Signatur mit dem Schlüssel der Antwort. Regel zwei vergleicht diesen Schlüssel mit dem, der im Register des Prüfers oder in einem aufgelösten DID-Dokument an agentDid gebunden ist. Der Draft untersagt ausdrücklich, dem eingebetteten publicKey allein zu vertrauen.

Frische, einmalige Nonce und ein vertrauenswürdiger issuerDid sind weitere Sperren. Keine erzeugt eine Identitätsbindung. Eine frische, nicht wiederholte Antwort eines ungebundenen Schlüssels bleibt eine Antwort eines ungebundenen Schlüssels.

Auch betrieblich sind die Kontrollen getrennt. Die Signaturprüfung kann verfügbar sein, während der Resolver ausfällt, ein altes Dokument liefert oder kompromittiert wurde. Ein korrektes DID-Dokument kann umgekehrt keine ungültige Signatur heilen. Ein gemeinsames grünes Feld vernichtet die für eine Untersuchung nötige Herkunft.

Die DID-Methode verteilt Benennungsmacht

Revision 03 verwendet did:web für providergebundene Identitäten. Der Provider stellt das DID-Dokument bereit. Domainkontrolle, TLS, Veröffentlichung, Cache und Wiederherstellung werden dadurch Bestandteil der Identitätsautorität.

did:opena2a ist für ökosystemweite Identitäten vorgesehen; deren Dokument wird nicht vom Identitätsprovider ausgeliefert. Die ältere Form did:aip:aim_ gilt als veralteter Alias. Prüflogik soll die Kennung als undurchsichtigen Wert behandeln und an den passenden Resolver geben, statt Vertrauen aus dem Präfix abzuleiten.

Das ist Governance, nicht Kosmetik. did:web übernimmt Verfügbarkeit und Wiederherstellung des Providers. Die Ökosystemmethode braucht eine andere Aktualisierung, Aufsicht und Streitbeilegung. Ein stiller Fallback zwischen beiden verschiebt Autorität, auch wenn er als Kompatibilität erscheint.

Der Draft vermerkt, dass der Referenzresolver am 8. September 2026 nur die alte Aliasform beantwortete. Das belegt keinen heutigen Produktionszustand, zeigt aber die Migrationslücke zwischen spezifizierter und tatsächlich verstandener Methode. Ein Entscheidungsnachweis muss Methode, Resolver und Dokument festhalten, die wirklich verwendet wurden.

Beschreibung ist keine Berechtigung

Der Agenten-type ist informativ und darf keine Sicherheitsentscheidung tragen. declaredPurpose kann Identitäts- oder Attestierungskontext liefern, doch sein Fehlen darf nicht automatisch ablehnen und sein Vorhandensein nicht autorisieren.

„Einkaufsagent“ oder „Rechercheassistent“ klingt nach Rolle, bleibt ohne unabhängige Bestätigung eine Selbstbeschreibung. Auch Vertrauenswertungen brauchen unabhängig prüfbare Eingaben.

Selbst eine korrekte Bindung beantwortet nur, wer den Schlüssel nutzen darf. Sie genehmigt keine Ausgabe, Konfigurationsänderung oder Verpflichtung. Identität, behauptete Fähigkeit, Autorisierung, Ausführung und reales Ergebnis benötigen getrennte Belege.