Zusammenfassung

  • Fassung -01 des individuellen Entwurfs zur Wallet State Attestation erschien am 27. September 2026. Sie ist weder RFC noch von einer IETF-Arbeitsgruppe übernommen oder als Einsatznachweis zu lesen.
  • Im JSON-Format umfasst das signierte Objekt auf oberster Ebene id, pass, results und attestedAt. Eine einzelne Bedingung kann eine Adresse enthalten; eine allgemeine Bindung an die abgefragte Wallet ergibt sich daraus nicht.
  • expiresAt und kid stehen neben den signierten JSON-Daten. Ein zusätzliches JWT signiert sub und exp eigenständig und muss auch eigenständig geprüft werden.

Genau vier Felder an der äußeren Grenze

Der überarbeitete Entwurf beschreibt einen Aussteller, der öffentlichen Blockchain-Zustand beobachtet, vom Betreiber vorgegebene Bedingungen auswertet und einen booleschen Befund signiert. Eine Gegenstelle kann den Befund anhand eines veröffentlichten JWKS offline prüfen. Nicht die Identität eines vorzeigenden Inhabers, sondern der beobachtete Zustand einer Wallet steht im Mittelpunkt. So lässt sich etwa die Erfüllung einer Schwelle melden, ohne den gesamten Kontostand mitzuteilen.

Die neue Fassung legt fest, dass für die JSON-Signatur genau vier Elemente des obersten Objekts rekonstruiert werden. Innerhalb von results sind auch die ausgewertete Bedingung und ihr Hash geschützt. Enthält eine solche Bedingung die Wallet-Adresse, ist diese ebenfalls Bestandteil der geschützten Daten. Das ist möglich, aber nicht vom Format insgesamt garantiert. Der ursprüngliche Anfragende kennt die Wallet aus seiner Anfrage. Eine zweite Stelle, an die der Befund ohne diese Anfrage weitergereicht wird, kann die Adresse möglicherweise nicht aus den signierten Bytes gewinnen.

Damit wird die Zuordnung zum Subjekt eine eigene Betriebsaufgabe. Eine korrekte Signatur beweist, dass der Aussteller diese Bytes signierte. Sie beweist nicht, dass ein nachgelagerter Dienst den Befund dem richtigen Kundenkonto zugeordnet hat. Ein Verwechslungsszenario ist noch kein Nachweis eines Angriffs oder eines fehlerhaften Produkts. Es zeigt aber, warum eine Zugangskontrolle nicht mit der Signaturprüfung enden darf.

Der Schlüsselhinweis ist keine Ausweichroute

kid steht beim JSON-Befund außerhalb der signierten Nutzdaten und bezeichnet den zu verwendenden Schlüssel sowie in Fassung -01 das Signaturverfahren. Der Verifizierer darf weder den ersten JWKS-Eintrag nehmen noch einen fest eingebauten Schlüssel ersatzweise einsetzen. Fehlt kid oder lässt es sich in den verfügbaren Schlüsseln nicht auflösen, ist der Befund nicht verifizierbar. Scheitert eine Signatur unter dem ausgewählten Schlüssel, ist sie widerlegt. Beide Fälle verhindern die Annahme; ihre Ursachen sind dennoch verschieden. Ein veralteter JWKS-Cache lässt sich gegebenenfalls auffrischen, ohne die Auswahlregel aufzuweichen.

Auch ein korrekt neu berechneter conditionHash erfüllt nur seinen eigenen Zweck. Er prüft, ob die übertragene ausgewertete Bedingung verändert wurde. Falls darin keine Wallet steht, erzeugt eine richtige Hashprüfung keine nachträgliche Subjektbindung. Die neue domänenseparierte JSON-Signatur und die fakultative Begleitsignatur ändern ebenso wenig die Bedeutung von Feldern, die nicht im signierten Gegenstand liegen.

Zwei Uhren, zwei Unterschriften

attestedAt und die kettenbezogenen Beobachtungsreferenzen innerhalb der Ergebnisse sind signiert. expiresAt wird im JSON dagegen als ungeschützter Hinweis auf die Gültigkeitsdauer mitgeschickt. Wer diese Angabe benötigt, soll sie laut Entwurf mit der signierten Uhrzeit und dem dokumentierten Zeitfenster des Ausstellers vergleichen. Eine eigene maximale Altersgrenze für den signierten Blockbezug kann zusätzlich verhindern, dass ein alter positiver Befund als aktuelle Berechtigung ausgelegt wird.

Die siebenstufige Verifizierungsanleitung macht hier einen Unterschied: Schlüsselauswahl, Rekonstruktion der signierten Bytes, Signatur und Bedingungs-Hash sind nach dem Entwurf verpflichtend; Frische und Ablaufprüfung werden empfohlen. Aus der Lektüre darf daher keine Behauptung entstehen, jeder denkbare Verifizierer würde eine einheitliche Frist durchsetzen. Die lokale Annahmeregel muss ausdrücklich benannt werden.

Das optionale JWT besitzt einen eigenen Signaturgegenstand. Es führt die tatsächlich ausgewertete Wallet als sub und das signierte Ablaufdatum als exp; auch kid steht im geschützten Header. Ein Empfänger, der diese Angaben nutzt, muss das JWT selbst verifizieren. Trifft es zusammen mit JSON ein, sieht die Fassung eine Prüfung entsprechender Werte vor; ein fehlerhaftes oder widersprechendes JWT lässt die gesamte Antwort scheitern. Die Gegenprüfung enthält keine Gleichsetzung von sub mit einem generellen JSON-Wallet-Feld, denn dieses Feld existiert dort nicht allgemein.

Merkle-Nachweise sind nur für geeignete Bedingungen und Ketten optional verfügbar. Sie können eine unabhängige Prüfung beobachteter Werte ermöglichen, zugleich aber Rohdaten wie den Kontostand preisgeben, den die binäre Antwort nicht verraten sollte. Auch diese technische Wahl ersetzt nicht die Entscheidung, zu welcher Anfrage das Ergebnis gehört.

Fassung -01 erläutert bestehende Signaturgrenzen und erweitert Verfahren sowie Ablehnungsfälle. Laut Änderungsanhang bleiben Signaturen der Fassung -00 gültig. Die September-Ausgabe hat also nicht erst die fehlende allgemeine Wallet-Bindung geschaffen. Im Datatracker steht ein aktiver individueller Internet-Draft ohne RFC-Stream, mit IESG-Status I-D Exists; die Plattform weist darauf hin, dass solche Einreichungen nicht IETF-gebilligt sind. Vom Autor erwähnte praktische Einsätze werden hier nicht als unabhängig belegte Einführung ausgegeben.

Quellen