Summary

  • Der individuelle Internet-Draft lässt einen Aussteller eine Wallet-Bedingung gegen einen referenzierten Chain-Zustand prüfen und einen über JWKS offline verifizierbaren Wahrheitswert signieren.
  • Im JSON-Format umfasst die Signatur id, pass, results und attestedAt; expiresAt, kid, Wrapper und meist die Wallet-Zuordnung liegen außerhalb dieser Bytes.
  • Eine gültige Signatur beweist die definierte Aussage des Ausstellers. Sie beweist weder Finalität noch aktuellen Zustand, Replay-Schutz oder die Berechtigung der nächsten Handlung.

Die Signatur blieb gültig, die Voraussetzung nicht

Ein Dienst fragt, ob eine Wallet noch den geforderten Einsatz hält. Der Aussteller liest eine Chain-Quelle, wählt einen Block, berechnet pass: true und signiert. Wenige Sekunden später ist die Prüfung fehlerfrei. Inzwischen kann der Einsatz übertragen, der Indexer verzögert oder der Block durch eine Reorganisation aus der kanonischen Geschichte gefallen sein.

Die Kryptografie hat nicht versagt. Sie hat die engere Aussage erhalten: Dieser Aussteller hat diese Auswertung mit diesen Ankern signiert. Erst die Oberfläche macht daraus „jetzt berechtigt“ und versteckt damit ihre eigene Entscheidung.

Revision 01 wurde am 27. September 2026 eingestellt. Datatracker führt sie als Individual Submission ohne Stream, Active und I-D Exists. Der Text profiliert JWT, JWKS und JOSE und definiert kein neues Wire-Protokoll. Er ist weder WG-Dokument noch IETF-Konsens, RFC, Interoperabilitätsnachweis oder Deployment-Bericht.

Vier signierte Mitglieder

Das signierte JSON-Objekt enthält id, pass, results und attestedAt. Jedes Ergebnis trägt die ausgewertete Bedingung, ihren conditionHash und eine Chain-Referenz: bei EVM Blocknummer und Zeit, bei XRPL Ledger-Index und gegebenenfalls Hash, bei Solana Slot, bei Bitcoin Höhe und Tip-Hash.

Das bare scheme hängt an der exakten übertragenen Member-Reihenfolge. Das neue domain-separated scheme setzt Nachrichtentyp und Version davor und nutzt RFC 8785. Das verbessert die reproduzierbare Bytefolge. Es attestiert weder RPC-Pfad noch Indexer, Datenverfügbarkeit oder Blockfinalität.

kid wählt Schlüssel und Schema im JWKS. Fehlt er oder ist unbekannt, lautet das Urteil unverifiable, nicht refuted; ein anderer Schlüssel darf nicht ersatzweise versucht werden. Unterschiedlich alte JWKS-Caches können Verifizierer während einer Rotation spalten. Das ist ein eigener Betriebszustand, keine automatisch erkannte Fälschung.

Auch die Wallet-Bindung ist formatspezifisch. Das signierte JSON benennt sie im Allgemeinen nicht. Manche Bedingungen tragen eine Adresse, andere nicht. JWT signiert sub und exp; wer diese Claims verwendet, muss das JWT selbst prüfen. Die benachbarte JSON-Signatur reicht nicht.

Aktualität entsteht aus Regeln über Anker

Chain-Referenz und attestedAt sind kryptografisch gebunden. Wie alt sie sein dürfen, legt der Verifizierer fest. Alter der Signatur, Alter des Blocks und Zeitpunkt der Handlung sind verschieden. Eine neue Signatur kann einen für Kapitalfreigabe zu alten Block referenzieren.

expiresAt ist im JSON nur ein unsignierter TTL-Hinweis. Revision 01 empfiehlt, ihn gegen signiertes attestedAt plus dokumentiertes Fenster zu begrenzen. Im JWT ist exp signiert. Da die Ablaufprüfung RECOMMENDED bleibt, muss die Quittung festhalten, ob sie ausgeführt wurde.

Replay braucht ebenfalls ein Profil. Die signierte id kann eine Seen-Liste speisen; Nonce und Audience sind nicht normativ festgelegt. Ein zeitlich akzeptables Artefakt kann dennoch in einer anderen Transaktion wiederverwendet werden.

Die Chain kann ihre Geschichte ändern

RPC-Routing, Indexer-Auswahl, Archive Node, Finalität und Data Availability sind außer Reichweite. Der Entwurf räumt ein, dass ein späterer Reorg den beobachteten Zustand nichtkanonisch machen kann. Bestätigungstiefe, starke Finalität, unabhängige Quelle und Widerruf sind Betreiberentscheidungen.

Die Neuberechnung von conditionHash erkennt eine veränderte Bedingung. Sie zeigt nicht, dass Chain, Block oder Geschäftsschwelle richtig waren. Ein Merkle-Beweis kann einen Wert an eine Root binden; die Root muss weiterhin als kanonisch und ausreichend final bewertet werden.

Damit laufen drei Uhren: Beobachtung des Ausstellers, Canonicality der Chain und Entscheidung des Dienstes. Die Signatur verbindet sie, sie synchronisiert sie nicht.

Der Quittungssatz

Lu Hengs Realitätsebenen trennen signierte Darstellung, Beobachtung, kanonischen Zustand, aktuellen Zustand und Anwendungsergebnis. Running-Code Primacy stellt reale Chain und Service über ein Label. Minimum Initial Specification hält das gemeinsame Format klein und macht Finalitäts- und Freigaberegeln lokal sichtbar.

Zu speichern sind Aussteller, kid, Schema und Domain Tag, Hash der rekonstruierten Bytes, primäres und Companion-Urteil, Condition Hash, Wallet-Bindung, Referenz, unabhängiger Abgleich, Finalitätstiefe, Zeiten, Ablauf-, Replay- und Audience-Entscheid, Freigaberegel und Handlungsergebnis.

Quellen und Grenzen

Diese Quellen belegen weder IETF-Konsens noch Adoption, Implementierung, Deployment, unabhängige Beobachtung, Finalität, Wallet-Kontrolle oder Zustimmung, Autorisierung, Settlement, Lieferung oder Dienstergebnis. Informative Adoptionshinweise im Entwurf bleiben Aussagen seiner Autoren.