Mandate, Identität & KundenzugriffGeprüft

Verifiable Intent

Verifiable Intent

Agent-Intent-Projekt; von Mastercard öffentlich vorgestellt

Draft v0.1 · Referenz-SDK Alpha
Stefan Hamann · Deutsch
Schrift

Die Aufgabe – und ihre Grenze

Verifiable Intent verbindet eine Benutzerfreigabe mit nachfolgenden Agentenhandlungen über eine kryptografische Delegationskette. Der Ansatz verwendet SD-JWT und macht die Grenzen einer Delegation prüfbar. Für Händler ist besonders wichtig, was genau bewiesen wird – und welche Geschäftsentscheidung trotzdem ihre eigene bleibt.

Nicht dafür gedacht: Kein Transportprotokoll, kein Settlement-System und nicht identisch mit dem kommerziellen Mastercard Agent Pay.

Wie es sich in den Stack einfügt

  • Mit AP2 kompatibler Autorisierungsbaustein.
  • Ergänzt Commerce- und Zahlungswege, statt Warenkorb oder Geldbewegung selbst zu definieren.

Release und Arbeitsfassung getrennt

Veröffentlichter Stand
0.1.0 (Changelog) ·
Arbeitsfassung
v0.1

Die öffentliche Mastercard-Ankündigung stammt vom 5. März 2026; das ist nicht das Changelog-Datum.

Lizenz / Bedingungen
Apache-2.0
Originalbedingungen prüfen ↗
Quellenprüfung
· Kein Installations- oder Konformitätstest

Ein konkreter Ablauf

Die Schritte ordnen die Rolle des Protokolls ein. Sie sind kein ausführbarer oder getesteter Quickstart.

  1. Die Benutzerfreigabe setzt Grenzen für eine Delegation.
  2. Weitere Handlungen werden an diese Delegation gebunden.
  3. Der Empfänger prüft die Nachweise und wendet seine eigenen Sicherheits- und Geschäftsregeln an.

SDKs und Implementierungswege

Die Einträge unterscheiden Bibliotheken, Modelle und Beispiele. Paketnamen sind Upstream-Einstiege, keine hier getesteten Installationsempfehlungen. Prüfen Sie vor der Integration die exakte Version und deren Spezifikationsunterstützung.

Offizieller ProjekteinstiegPython

Verifiable Intent Python

Artefakt: Referenz-SDK

Paket / Modul: verifiable-intent

Version & Kompatibilität: Paketmetadaten 0.1.0, Alpha; Python ≥3.10

Registry-Latest nicht bestätigt; offizielle TS/Go/Java/PHP-SDKs hier nicht verifiziert.

Was für den Betrieb offen bleibt

  • Die Referenzimplementierung bezeichnet sich als Alpha; daraus keine Produktionsfreigabe ableiten.
  • Schlüssel, zulässige Grenzen und Replay-Behandlung im konkreten System prüfen.

Eine offene Spezifikation erteilt keine automatische Erlaubnis für Zahlungen oder Verkaufskanäle. Testmodus, Benutzerfreigabe und Produktionszulassung bleiben eigene Schritte.

Originalquellen

Redaktioneller Stand: . Ein Versionsstand gilt für die genannte Spezifikation oder Bibliothek, nicht automatisch für andere Sprachpakete. „Nicht verifiziert“ bedeutet nicht „existiert nicht“.