Zusammenfassung

  • Die PrivateToken-Challenge legt Typ, Aussteller, Einlösungskontext, Origin-Menge und Schlüssel fest; das Token bindet sich an den Digest dieser exakten Frage.
  • Bei offenen Diensten kann selbst ein fähiger Client mit nichttrivialer Wahrscheinlichkeit nicht antworten. Schweigen soll Support, Störung und bewusste Wahl gerade nicht unterscheiden.
  • Challenge, Prüfung, Vorrat, Antwortwahl, Ausgabe, Verifikation, Replay, Autorisierung, Nebenwirkung und Lieferung brauchen getrennte Belege.

Die Kennzahl hatte ihren Nenner erfunden

Ein Betreiber teilte die Zahl empfangener Tokens durch die Zahl gesendeter Challenges und nannte das Ergebnis „Client-Unterstützung“. Der Zähler war beobachtet. Der Nenner war eine Behauptung: Er setzte voraus, dass jeder fähige Client antworten musste.

RFC 9577 verwirft diese Voraussetzung. Ein unbekannter Typ, eine fehlerhafte Struktur oder eine origin_info-Liste ohne den herausfordernden Origin beendet die Verarbeitung. Es kann kein passendes Cache-Token geben, der Aussteller kann unerreichbar sein, eine lokale Regel kann widersprechen oder die Sitzung kann enden. Außerdem darf ein vollständig fähiger Client absichtlich schweigen.

Bei einem Dienst, der ohne Token offen bleibt und damit etwa CAPTCHA-Häufigkeit reduziert, können fähige Clients Challenges mit nichttrivialer Wahrscheinlichkeit ignorieren. Vom Origin aus sehen sie dann aus wie nicht unterstützende oder vorübergehend handlungsunfähige Clients. Diese Ununterscheidbarkeit ist Schutz, nicht Messfehler.

Vier Felder begrenzen die Frage

token_type bestimmt Ausgabeprotokoll und Struktursemantik. issuer_name benennt den zugelassenen Aussteller. redemption_context bindet an keinen, einen anfragebezogenen oder einen sitzungsbezogenen Kontext. origin_info enthält leer oder exakt die akzeptierenden Origins. Daneben liefert der Header den token-key.

Der Client prüft Typ, Form und Origin-Bindung, bevor er ein Token holt oder einlöst. Scheitert eine Pflichtprüfung, darf er nicht fortfahren. Besteht sie, darf er dennoch zusätzliche lokale Anforderungen stellen.

Die Challenge belegt daher nur, was der Origin angeboten hat. Sie belegt weder installierte Fähigkeit noch Vertrauen in den Aussteller, passenden Bestand, Antwortwillen oder Geschäftsberechtigung. Ein standardisierter Koordinatensatz ist kein Vollstreckungsauftrag.

Starke Bindung ist kein allgemeiner Leumund

Das Token enthält einen Client-Nonce, SHA-256 über die vollständige Challenge, die Schlüsselkennung und einen Authenticator. Ein Cache-Token passt nur bei identischem Typ, Aussteller, Kontext und identischer Origin-Zeichenfolge.

Diese Genauigkeit schränkt die Aussage ein. Ein gültiger Authenticator sagt nichts über bürgerliche Identität, Menschlichkeit, gute Absicht oder das Recht auf eine beliebige Aktion. Schon eine anders sortierte Origin-Liste ist eine andere Zeichenfolge. Ein verbreiterter Geltungsbereich kann nicht still aus einem alten Token abgeleitet werden.

Nach dem Löschen von Cookies oder einem Netzwechsel kann ein kontextgebundener Vorrat zu verwerfen sein. Sonst verbindet seine spätere Einlösung zwei Zustände, die getrennt erscheinen sollten. Ein nicht vorgelegtes Token kann somit der korrekte Datenschutzpfad sein.

Der Origin bestimmt die Kosten seiner Frage

Mehrere Challenges können Typen, Aussteller oder Kontexte anbieten. Ihre Reihenfolge ist ein Hinweis; der Client wählt. Zu viele Optionen belasten ihn. Ein je Anfrage einzigartiger Kontext verhindert Cache-Nutzung und erzwingt eine neue Ausgabe.

Sinkt danach die Antwortquote, ist das keine reine Eigenschaft der Clients. Der Origin hat den preiswerten Pfad entfernt. Eine belastbare Messung muss die Fragekonfiguration neben der Antwort erfassen.

Greasing hält unbekannte Zukunftswerte gangbar. Reservierte Zufallstypen sollen gelegentlich auftauchen und sicher ignoriert werden. Wo Tokens nicht Pflicht sind, soll der Origin gelegentlich gar nicht herausfordern. Erhält ein reservierter Wert eine Risikostufe, hat der Test die Verhärtung der eigenen Entscheidungskette gefunden.

Replay erhält seine Bedeutung vom Effekt

Die kryptografische Prüfung ist nur eine Station. Der Origin muss den Nonce-Zustand auswerten. Doppelausgabe soll verhindert werden, doch Wiederholung ist nicht immer ein Angriff: Wo Anfragen ohnehin verknüpfbar sind und Einlösung keine Nebenwirkung auslöst, kann sie vertretbar sein. Zahlung, Löschung oder Reservierung, besonders in 0-RTT, verlangt eine andere Kontrolle.

Darum sind Gültigkeit, Replay-Entscheid, Anwendungsautorisierung, Commit und Lieferung getrennt zu protokollieren. Der Kryptoprüfer kennt den wirtschaftlichen Effekt nicht. Die Anwendung kennt ohne Zustandsspeicher die Nonce-Historie nicht.

Spiegelbildlich kennt ein fehlendes Token keine Ablehnungsbegründung. Diese Entscheidung stammt von einer Policy und muss ihr zugerechnet werden.

Gemeinsame Origins teilen Verpflichtungen

Cross-Origin-Tokens erleichtern Vorab-Ausgabe, verlangen aber identische Challenge-Semantik und gemeinsamen Double-Spend-Zustand. Asynchrone Speicher können dasselbe Token mehrfach akzeptieren. Ein Origin kann außerdem den Vorrat des Clients leeren und damit andere Mitglieder beeinträchtigen.

Der Client darf nach einer Einlösung innerhalb eines Zeitfensters weitere Präsentationen stoppen. Das Schweigen schützt Bestand. Wird es bestraft, erhält ein Mitglied der Gruppe Macht über den Zugang bei den anderen.

Der Betriebsvertrag muss Synchronisation, Verbrauchsgrenzen, Fehlerbehandlung, Haftung und Austritt benennen. Die übertragene origin_info-Liste beweist lediglich Konfiguration, nicht die Erfüllung dieser Pflichten.

Ein Register ist kein Betriebsnachweis

IANA koordiniert Namen und Nummern. RFC 9576 beschreibt Rollen; RFC 9578 sowie VOPRF und blinde RSA-Signaturen beschreiben Ausgabe. Daraus folgt keine Aussage über einen bestimmten Browser, erreichbare Aussteller, organisatorische Unabhängigkeit, synchronen Replay-Schutz oder gleichwertigen Dienst ohne Token.

Running-Code-Primat verlangt lokale, verhältnismäßige Belege. Der Standard beschreibt erlaubte Übergänge. Telemetrie zeigt den tatsächlichen Übergang. Wer ablehnt, muss die eigene Regel mit Version und Verantwortlichem nennen, statt sie einer ausgebliebenen Nachricht zuzuschreiben.

Quellen

Quellen