Zusammenfassung

  • Wechselt der Schlüssel zwischen dem Abruf von Session und dem Anlegen eines Push-Abonnements, kann dessen Verifikation zurückgewiesen werden. Der Server darf diese Verifikation nicht wiederholen; der Client muss den zurückgegebenen Sitzungszustand prüfen.
  • Das technische Erratum 9055 beanstandet einen optionalen letzten Benachrichtigungsweg in RFC 9749. Es war bei der Prüfung weiterhin als Reported geführt und ist keine bereits bestätigte Änderung des Standards.

Ein sauber dokumentierter Schlüsselwechsel kann trotzdem eine unsaubere Übergabe hinterlassen. Der Server verwendet den neuen Schlüssel, der Auftrag ist erledigt, die Betriebsakte geschlossen. Auf dem Endgerät wartet jedoch ein neu angelegtes Abonnement auf seine Verifikation. Das Warten endet nicht durch den nächsten Sendeversuch, denn dieser Versuch ist in der betreffenden Situation ausdrücklich nicht vorgesehen.

RFC 9749 beschreibt genau diesen Fall für JMAP Web Push. Das im März 2025 veröffentlichte Dokument führt VAPID zur Authentifizierung des Anwendungsservers ein. Es regelt auch, was passiert, wenn sich dessen Schlüssel während der Einrichtung eines Abonnements ändert.

Daraus folgt keine Aussage über einen konkreten Ausfall. Die hier geprüften Quellen belegen weder betroffene Anbieter noch verlorene Nachrichten oder eine Fehlerquote. Sie liefern vielmehr einen präzisen Abnahmepunkt: Wer erkennt eine überholte Schlüsselannahme, wenn der Sender die abgewiesene Verifikation nicht erneut versuchen darf?

Zwei Zeitpunkte statt einer gemeinsamen Transaktion

Der Client erfährt den öffentlichen Anwendungsschlüssel aus dem Session-Objekt. Anschließend richtet er einen daran gebundenen Push-Endpunkt ein und meldet das Abonnement bei JMAP an. Zwischen der ersten Information und PushSubscription/set kann der Server den Schlüssel wechseln.

Dann treffen zwei korrekte Informationen aus unterschiedlichen Zeitpunkten aufeinander. Der Push-Endpunkt ist noch an den alten öffentlichen Schlüssel gebunden, die Verifikationsnachricht wird bereits unter dem neuen Schlüssel authentifiziert. Der Push-Dienst kann mit 403 ablehnen.

Die Bindung ist eine Schutzfunktion, kein bloßer Verwaltungsrest. RFC 8292 verlangt bei einem eingeschränkten Abonnement einen Nachweis mit dem privaten Schlüssel, der zum bei der Einrichtung angegebenen öffentlichen Schlüssel gehört. Könnte der Absender diese Vorgabe eigenmächtig durch seinen jeweils neuesten Schlüssel ersetzen, wäre die Einschränkung aufgehoben. Für einen neuen öffentlichen Schlüssel ist deshalb ein neues Abonnement nötig.

Allerdings ist 403 keine eindeutige Fehlerursache. Auch eine ungültige Signatur, ein falscher Empfängerbezug des Tokens oder ein Ablaufproblem können die Authentifizierung scheitern lassen. Eine belastbare Diagnose verbindet den Zeitpunkt des Anlegens mit der Schlüsselgeneration und dem Session-Zustand. Wer jeden 403 als Rotation behandelt, kann viele neue Abonnements erzeugen, ohne den eigentlichen Fehler zu beseitigen.

Ebenso wichtig ist die Trennung der Schlüsselarten. VAPID authentifiziert den Anwendungsserver. Die Verschlüsselung des Nutzinhalts erfüllt eine andere Aufgabe; Signatur und Schlüsselaustausch für die Verschlüsselung müssen unterschiedliches privates Schlüsselmaterial verwenden. Erfolgreiche Authentifizierung beweist weder Zustellung noch Kenntnisnahme durch den Benutzer.

Der relevante Zustand steht außen

RFC 8620 verlangt zunächst einen Verifikationscode, den der Client korrekt zurückgeben muss. Erst danach darf der Server die weiteren Anfragen an die Push-Adresse schicken. Ein angenommenes Abonnement ist somit noch kein fertig eingerichteter Benachrichtigungskanal.

Für die Wiederherstellung ist eine Besonderheit der Schnittstelle entscheidend: PushSubscription/set kennt kein ifInState. Auch oldState und newState gehören nicht zu seinem Ergebnis. Die übliche Prüfung einer Datenkollektion kann hier also nicht einfach übernommen werden. Der maßgebliche sessionState befindet sich in der äußeren API-Antwort und verweist auf den Zustand des Session-Objekts.

RFC 9749 verpflichtet den Client, diesen Zustand gegen die erwartete applicationServerKey-Information zu prüfen. Bei einer Abweichung darf er die Erstellung erneut versuchen und den erfolglosen vorherigen Versuch entfernen. Das ist eine Rekonstruktion auf aktueller Grundlage, keine Aufforderung zur endlosen Wiederholung unveränderter Annahmen.

Der Server darf die zurückgewiesene PushVerification dagegen nicht erneut senden. Diese Aussage ist eng zu lesen: Sie verbietet nicht pauschal jeden Wiederholungsversuch für jede Push-Nachricht. Sie trennt die erfolglose Verifikation des alten Versuchs von einer neuen, passend gebundenen Registrierung.

Eine Abnahmeanzeige mit nur einem Feld „abonniert“ kann diese Unterscheidung verschlucken. Wurde die Erstellung angenommen? Ist der Code zurückgekommen? Ist die Verifikation abgeschlossen, und zu welcher Schlüsselgeneration gehört das Ergebnis? Für Benutzer müssen diese Details nicht sichtbar sein. Im Betriebsnachweis dürfen sie nicht verschwinden.

Andernfalls kann eine ausbleibende Meldung als normale Ruhe fehlinterpretiert werden. Der Dienst hat vielleicht nichts Neues mitzuteilen; vielleicht besteht aber auch noch kein verifizierter Kanal. Diese Alternativen verlangen unterschiedliche Untersuchungen, auch wenn sie auf dem Bildschirm identisch aussehen.

Ein letzter Hinweis mit offener Schnittstellenfrage

Für gewöhnliche Rotation lässt RFC 9749 einen Übergang zu, in dem alte Abonnements noch mit dem zugehörigen alten Schlüssel bedient werden. Am Ende dieses Zeitraums, oder sofort ohne Übergang, muss der Server die alten Abonnements zerstören. Eine bestimmte Dauer schreibt der Standard nicht vor.

Zusätzlich beschreibt der ursprüngliche Text eine optionale letzte StateChange-Nachricht. Sie soll einen PushSubscription/changes-Aufruf auslösen und so zum neuen Session-Zustand führen. Gerade diese Passage sollte in einem Betriebshandbuch nicht ungeprüft zur Rückversicherung werden.

Erratum 9055 im RFC-Editor-Verzeichnis, am 31. Juli 2026 von Neil Jenkins gemeldet, schlägt ihre Streichung vor. PushSubscription sei keinem Konto zugeordnet und passe deshalb nicht in die angegebene StateChange-Struktur; außerdem definiere RFC 8620 keine Methode PushSubscription/changes.

Bei der Prüfung am 7. September 2026 lautete der Status weiterhin Reported, nicht Verified. Die vorgeschlagene Korrektur ist also nicht bereits geltender Ersatztext. Die beiden Schnittstellenbeobachtungen lassen sich dennoch im Basisstandard nachvollziehen. Daraus folgt eine begrenzte, praktische Konsequenz: Die beanstandete Aufrufkette ist kein nachgewiesener, verlässlicher Interoperabilitätsweg.

Selbst eine einwandfreie letzte Meldung könnte nicht jeden ruhenden Client erreichen. RFC 8030 begrenzt die Aufbewahrung durch die Nachrichtenlebensdauer; ein Push-Dienst darf diese verkürzen. Bei einer Lebensdauer von null wartet die Nachricht nicht auf ein gerade unerreichbares Gerät. Die Bezeichnung „letzte Warnung“ schafft keine Zustellgarantie.

Zu prüfen ist daher der Rückkehrfall: Was macht der Client, wenn er ohne empfangene Warnung wieder aktiv wird? Der IANA-Eintrag für die JMAP-Erweiterung beantwortet diese Frage nicht. Er dokumentiert den vereinbarten Bezeichner, nicht die Wiederanlauffähigkeit bestimmter installierter Versionen.

Nachvollziehbarkeit ohne zweites Geheimnisarchiv

Für eine Untersuchung sind Schlüsselgeneration, Annahmezeitpunkt, Verifikation und Stilllegung hilfreiche Stationen. Dafür müssen weder die vollständige Push-URL noch Verschlüsselungsgeheimnisse dauerhaft im Protokoll stehen.

RFC 8620 fordert deren sichere Löschung beim Zerstören des Abonnements. PushSubscription/get darf URL und Schlüssel nicht zurückgeben, selbst wenn ausdrücklich danach gefragt wird. Sinnvolle Betriebsdaten können aus nicht geheimen Generationskennungen, begrenzt aufbewahrten Zeitstempeln und Ergebnissen bestehen. Eine vollständige Kopie zu Diagnosezwecken würde dem bereits entfernten Material eine zusätzliche Lebensdauer verschaffen.

Auch die Zugangsdaten zur API setzen eine Grenze: An sie ist die Lebensdauer des angelegten Abonnements gekoppelt. Widerruf und Ablauf sind nicht bloß weitere Transportstörungen. Ein Client sollte zudem keine Abonnements verändern, deren deviceClientId er nicht als eigene erkennt.

Eine Wiederherstellung, die zur Bequemlichkeit alle Gerätebeziehungen löscht, erweitert ihren Auftrag. Der lokale Erfolg wäre durch Unterbrechungen an anderer Stelle erkauft. Gerade Korrekturverfahren müssen deshalb ihren Umfang ausdrücklich wahren.