Résumé

  • Lorsque la clé change entre la lecture de la session et la création d'un abonnement, la vérification peut être rejetée. Le serveur ne doit pas renouveler cette vérification ; le client doit contrôler l'état de session retourné.
  • Un erratum technique signalé en juillet 2026 conteste le mécanisme facultatif de dernière notification décrit par RFC 9749. Son statut reste « Reported » : il faut examiner le problème sans présenter la correction proposée comme déjà adoptée.

Qui reprend le dossier lorsqu'un service a terminé son intervention, mais que le suivant ne peut pas achever la sienne ? Dans une organisation, cette question produit des files d'attente. Dans un protocole, elle peut produire un client qui attend un message dont l'expéditeur n'a pas le droit de renouveler l'envoi.

Le cas figure dans RFC 9749, publié en mars 2025. Le document introduit l'authentification VAPID pour les notifications Web Push de JMAP. Son intérêt opérationnel ne se limite pas au choix d'une signature : il décrit un intervalle où le client et le serveur ne partagent plus la même hypothèse sur la clé applicable à un nouvel abonnement.

Aucune panne d'un fournisseur n'est établie par les sources examinées. Il s'agit d'une situation prévue par le protocole, utile pour évaluer une procédure de changement. Elle montre pourquoi une rotation ne peut pas être jugée seulement au moment où le serveur commence à signer avec sa nouvelle clé.

Un abonnement construit sur un état déjà dépassé

Le client obtient la clé publique du serveur d'application dans l'objet Session. Il prépare ensuite un abonnement de poussée lié à cette clé. Si une rotation intervient dans l'intervalle précédant PushSubscription/set, le message de vérification peut être signé avec la nouvelle clé alors que le point de terminaison reste lié à l'ancienne. Le service de poussée le rejette alors avec un code 403.

Ce refus protège une propriété voulue. RFC 8292 lie un abonnement restreint à la clé publique fournie lors de sa création. L'expéditeur doit prouver qu'il possède la clé privée correspondante. Accepter la clé que l'expéditeur préfère aujourd'hui supprimerait cette restriction au lieu de réparer l'abonnement.

Mais le code 403 ne suffit pas à désigner la rotation comme cause. Une signature invalide, une mauvaise audience ou un problème d'expiration du jeton peuvent aussi conduire à un rejet d'authentification. La chronologie, la génération de clé et l'état de session doivent corroborer le diagnostic. Une reconstruction systématique après tout refus risque de multiplier les opérations sans corriger l'erreur.

L'expression « changer la clé » demande elle-même de la précision. La signature VAPID identifie le serveur d'application. Le chiffrement du contenu répond à une autre exigence, et les clés privées employées pour la signature et l'échange de clés de chiffrement doivent être distinctes. Ni l'une ni l'autre de ces opérations ne prouve que le destinataire a reçu ou lu une notification.

Le contrôle se trouve dans la réponse extérieure

Dans RFC 8620, la vérification initiale évite d'envoyer librement des requêtes à une adresse que le client ne peut pas utiliser. Le serveur attend le retour du bon code de vérification avant d'envoyer les requêtes suivantes. Une création acceptée ne constitue donc pas encore un canal opérationnel.

La particularité du cas apparaît dans la méthode de contrôle. PushSubscription/set ne possède pas de condition ifInState, ni de champs oldState et newState dans son résultat. Il ne faut pas lui prêter le mécanisme de concurrence d'une collection ordinaire. Le sessionState pertinent se trouve dans la réponse API extérieure et permet de constater qu'il faut réexaminer l'objet Session.

RFC 9749 demande au client de vérifier cette cohérence avec la clé attendue. Il autorise une nouvelle tentative de création et la destruction de l'abonnement précédent qui n'a pas abouti. En revanche, le serveur ne doit pas réessayer la vérification rejetée. Ce partage des tâches est plus subtil qu'une consigne générale de relance : une partie doit abandonner son ancienne hypothèse pour que l'autre puisse de nouveau agir utilement.

Il serait tout aussi faux d'en déduire que toutes les notifications sont interdites de réessai. La règle vise ici le PushVerification rejeté dans cette situation. Recréer un abonnement correctement lié n'est pas répéter indéfiniment la même requête dans les mêmes conditions.

Un tableau de bord qui rassemble sous « abonnement actif » la demande acceptée, le code reçu et la liaison vérifiée avec la clé actuelle masque précisément le passage à surveiller. L'interface destinée à l'utilisateur peut rester simple. Les états exploités par le service, eux, doivent permettre de retrouver l'endroit où la progression s'est arrêtée.

La dernière alerte n'est pas un contrat de réception

Le texte initial de RFC 9749 propose une notification StateChange facultative lors du retrait de certains abonnements associés à l'ancienne clé. Elle est censée provoquer un appel PushSubscription/changes, puis la découverte du nouvel état de session. Cette séquence mérite une réserve explicite.

L'erratum 9055 dans le registre de RFC Editor, signalé par Neil Jenkins le 31 juillet 2026, propose de supprimer le paragraphe. Il relève que PushSubscription n'est pas associé à un compte permettant son insertion dans la structure StateChange décrite, et que RFC 8620 ne définit aucune méthode PushSubscription/changes.

Au 7 septembre 2026, l'enregistrement porte toujours le statut Reported, et non Verified. La proposition n'est donc pas une modification normative déjà incorporée. Les deux observations sur l'interface se vérifient néanmoins dans RFC 8620. Une procédure d'exploitation ne devrait pas présenter la chaîne contestée comme une garantie d'interopérabilité, en attendant simplement que la notification finale réveille tous les clients.

Même un avertissement techniquement valide ne garantirait pas ce réveil. RFC 8030 encadre la durée de conservation des messages ; le service peut la réduire, et un message à durée de vie nulle ne reste pas en attente d'un appareil indisponible. La décision d'envoyer une « dernière » notification n'ajoute aucune capacité de réception au terminal dormant.

Le critère utile devient la capacité du client à découvrir la modification lorsqu'il reprend son activité. C'est une propriété à démontrer sur les versions prises en charge, pas à déduire d'une formule dans un plan de migration. De même, l'inscription de l'extension au registre JMAP d'IANA atteste l'identifiant convenu ; elle ne certifie ni la diffusion de l'extension ni le comportement d'un parc installé.

Une trace de reprise n'est pas une copie des secrets

Les équipes ont besoin de distinguer les générations de clés, les tentatives acceptées, les vérifications terminées et les abonnements retirés. Cela n'oblige pas à conserver les URL de poussée complètes ou les secrets de chiffrement dans les journaux.

RFC 8620 impose leur effacement sécurisé lors de la destruction de l'abonnement. La méthode PushSubscription/get ne doit pas les retourner, même s'ils sont demandés. Une observation utile peut reposer sur des identifiants non secrets de génération et sur des horodatages dont la conservation est limitée. Sauvegarder toutes les données « au cas où » réintroduirait une durée de vie pour des éléments que le service vient de retirer.

Les identifiants d'accès ayant servi à créer l'abonnement délimitent aussi sa durée de vie. Leur révocation ne doit pas être traitée comme une simple panne de transport. Et un client ne devrait pas modifier les abonnements dont il ne reconnaît pas le deviceClientId. La reprise d'un terminal n'autorise pas la remise à zéro des relations de tous les autres.

Ces limites évitent un piège fréquent dans les procédures correctives : obtenir un résultat local en élargissant silencieusement le périmètre de l'action. Un canal reconstruit au prix de la disparition de ceux des autres appareils n'est pas un succès de continuité.