Zusammenfassung

  • Revision 01 von Using KYAPay Tokens vom 2. Oktober 2026 nennt die konsumierende Stelle nicht länger „Verifier“, sondern „Recipient“. Identifikation ist ausdrücklich nicht Zulassung: Ein gültiges Token liefert authentisierten Kontext, während der Empfänger zulässt, drosselt, zusätzliche Prüfung verlangt oder ablehnt.
  • Ein positives Prüfergebnis trägt nicht jede spätere Behauptung. Ein Bearer-Token beweist keinen privaten Schlüssel, eine Autorisierung bei Ausstellung keine dauernde menschliche Kontrolle und ein PAY-Kontext weder Händlerannahme noch endgültige Abrechnung.

Die entscheidende Änderung in draft-skyfire-oauth-using-kyapay-tokens-01 ist die Benennung eines Machtortes. Wer das Token erhält, ist nicht nur ein Baustein, der wahr oder falsch meldet. Als Recipient steht er vor einer eigenen Entscheidung.

Das kann ein Ressourcenserver, Edge-Anbieter, Bot-Manager, Betrugssystem, Schutz vor Kontoübernahme oder eine Kundenidentitätsplattform sein. Dieselbe Signatur kann bei allen gültig sein und dennoch zu verschiedenen Handlungen führen. Das Risiko einer öffentlichen Leseanfrage unterscheidet sich von Kontowiederherstellung oder bindendem Kauf.

KYA beschreibt Koordinaten des menschlichen Principals, der Agentenplattform und der konkreten Agenteninstanz. PAY ergänzt Zahlungskontext. Das ist belastbarer als eine Vermutung aus IP-Adresse und User-Agent. Die Aussage lautet aber: „Dieser Aussteller ordnet diese Beteiligten zu.“ Sie lautet nicht: „Der Zielservice muss handeln.“

Revision 01 trennt deshalb identification und admission. Das Token ist Eingang einer lokal konfigurierten Policy Engine. Zulassen, begrenzen, Step-up oder ablehnen bleiben mögliche Ausgänge. Ein einziges grünes Kennzeichen „verifizierter Agent“ würde Assurance-Stufen und Folgen der verlangten Aktion unsichtbar machen.

Auch der Dokumentstatus darf nicht hochgestuft werden. Beide KYAPay-Texte sind individuelle Internet-Drafts. Die eingefrorenen Datatracker-Datensätze zeigen weder Stream noch Standards Level oder WG-Annahme. Die OAuth-Liste ist Diskussionsort, kein Konsensnachweis. Beantragte HTTP-Felder und JWT-Claims sind erst dann IANA-Zuweisungen, wenn die aktiven Register sie führen.

Die Validierung besteht aus getrennten Kontrollen. Der Empfänger wählt vertrauenswürdige Aussteller, prüft JOSE-Header und Signatur, danach exp, iat, jti, aud und Umgebung. Er bestimmt den Token-Typ und bewertet die Assurance für Mensch, Plattform und Agent einzeln. Die Anwesenheit eines KYAPay-Token-Headers ist kein Nachweis menschlicher Gegenwart.

Standardmäßig beschreibt das Profil Bearer-Tokens. Wer ein Token kopiert, kann es während seiner Gültigkeit präsentieren. TLS, kurze Laufzeit, enge Audience und Replay-Speicher verkleinern das Fenster, beweisen jedoch nicht die Kontrolle über einen privaten Agentenschlüssel.

Die begleitende Token-Revision 02 erlaubt cnf. Damit lässt sich Bestätigungsschlüsselmaterial referenzieren. Sender Constraint entsteht aber nur, wenn das umgebende Protokoll einen tatsächlichen Proof verlangt und der Empfänger ihn prüft. Ein Schlüsselverweis im signierten Objekt ist nicht der kryptografische Vorgang. Signatur und Schlüsselbesitz gehören in getrennte Belegfelder.

Autorität altert. Ein gültiges Token bestätigt laut Entwurf die Bevollmächtigung bei Ausstellung, nicht die ununterbrochene menschliche Steuerung. Danach kann ein Host kompromittiert, eine Plattform deregistriert oder ein Mandat widerrufen werden. Revision 01 definiert keinen Revocation-Mechanismus. Je folgenreicher die Aktion, desto wichtiger ist eine frische Challenge.

Ausstellervertrauen ist ebenfalls lokale Policy. Eine korrekte Signatur belegt den signierenden Schlüssel, nicht die Güte von Identitätsprüfung, Agentenregistrierung oder Plattformkontrollen. Der Entwurf bezeichnet skalierbares Issuer Trust als offenes Problem und verweist auf bestehende Out-of-band-Beziehungen. Die verwendete Trust-List-Version ist daher Teil des Entscheidungsbelegs.

PAY ist schließlich kein Zahlungsabschluss. Ziel, Betrag, Währung, transaktionsgebundene Credential und einmaliges Kryptogramm erschweren Wiederverwendung und erlauben Parameterabgleich. Sie belegen weder Händlerannahme noch Netzwerkautorisierung, Clearing, endgültiges Settlement, fehlende Rückbuchung oder Lieferung.

Ein belastbarer Receipt speichert genaue Draft- und Profilversion, Aussteller und Key Set, Assurance und zugrunde liegende Evidence, unveränderlichen Token-Hash, Signatur- und Claim-Ergebnisse, Audience und Umgebung, Replay-Entscheidung, Bearer oder Schlüssel-Proof, Policy und Step-up sowie die finale Anwendungsaktion. Bei Zahlungen bleiben Autorisierung, Clearing, Settlement und Reversal eigene Referenzen.

Heng Lus Minimum Initial Specification liefert das Designprinzip: minimale gemeinsame Claims und Invarianten, aber lokale folgensensitive Policy. Running-Code Primacy richtet den Blick auf die tatsächlich ausgeführte Anwendung. Reality Layers verhindert, dass Ausstelleraussage, Kryptografie, Schlüsselbesitz, Policy und sichtbares Resultat unter „autorisiert“ verschwinden.

„Recipient“ ist damit keine Stilkorrektur. Der Aussteller attestiert, das Token transportiert, der Validator prüft. Der Empfänger verwaltet seine Schnittstelle, und die Anwendung belegt ihre wirkliche Handlung.

Quellen