Esperar no es un plan de recuperación

Resumen

• Si cambia la clave entre la consulta de Session y el alta de la suscripción, la verificación puede ser rechazada. El servidor no debe repetir esa verificación; el cliente tiene que comprobar el sessionState recibido.
• La errata técnica 9055 propone eliminar el mecanismo opcional de último aviso descrito en RFC 9749. Seguía en estado Reported al consultarla: es una objeción documentada, no una corrección normativa ya aprobada.

Una orden de cambio puede cerrarse con dos pruebas impecables: la nueva clave está activa y la solicitud de suscripción recibió respuesta. Falta una tercera: que el cliente haya podido verificar la suscripción y disponga de un canal utilizable. Si esa prueba no pertenece a nadie, el expediente está cerrado antes de que termine el trabajo.

RFC 9749, de marzo de 2025, permite describir esa discontinuidad sin inventar un incidente. La extensión incorpora VAPID a Web Push en JMAP y contempla un cambio de clave en mitad del alta. En ese caso, la verificación puede no llegar y el servidor tiene prohibido volver a intentar la verificación rechazada. La recuperación requiere que el cliente advierta que su información de partida ha quedado obsoleta.

No se ha establecido aquí que un proveedor haya perdido correo, que exista una avería generalizada o que una proporción determinada de dispositivos esté afectada. El valor del caso es otro: obliga a sustituir una expectativa vaga de reintento por una responsabilidad concreta.

El alta tiene un intervalo que importa

El cliente consulta el objeto Session para conocer la clave pública del servidor de aplicaciones. Después utiliza un punto de conexión de push asociado a esa clave al crear la suscripción JMAP. El servidor puede rotar su clave entre ambas operaciones.

Si la verificación se firma entonces con la nueva clave, pero el punto de conexión quedó restringido a la anterior, el servicio de push responde con un rechazo de autenticación. El 403 descrito por RFC 9749 representa una discrepancia entre dos momentos, no necesariamente una firma calculada de manera defectuosa.

La vinculación no es un obstáculo arbitrario. RFC 8292 exige que una suscripción restringida reciba autenticación demostrada con la clave privada correspondiente a la pública utilizada al crearla. Permitir al remitente sustituirla unilateralmente por cualquier clave nueva vaciaría de contenido esa protección. Cambiar de clave pública exige establecer una nueva suscripción.

Eso no convierte cada 403 en una prueba de rotación. Un destinatario de token incorrecto, una firma inválida o un problema de caducidad también pueden provocar rechazo. Para atribuirlo a esta carrera hacen falta el momento del alta, la generación de clave y el estado de sesión. Un procedimiento que reconstruye todo ante cualquier 403 puede ser muy activo y estar equivocándose de problema.

Tampoco conviene mezclar autenticación y confidencialidad. VAPID identifica al servidor de aplicaciones; el cifrado protege el contenido mediante material de clave distinto. Las claves privadas de firma y de intercambio para cifrado deben ser diferentes. Superar una comprobación de identidad no demuestra recepción, lectura ni ejecución de una acción por parte del usuario.

El cliente debe mirar fuera del resultado del alta

Según RFC 8620, el servidor envía primero un código de verificación y espera que el cliente lo devuelva correctamente antes de realizar las solicitudes siguientes. El registro aceptado y la verificación terminada son, por diseño, hitos separados.

Hay un detalle decisivo para quien implemente o evalúe la recuperación: PushSubscription/set no admite ifInState y no devuelve oldState ni newState. No ofrece la condición de concurrencia de una colección convencional. El dato pertinente es sessionState, situado en la respuesta exterior de la API, que permite detectar la necesidad de revisar Session.

RFC 9749 exige comprobar esa información frente a la applicationServerKey esperada. Cuando descubre la discrepancia, el cliente puede intentar crear de nuevo la suscripción y puede destruir la tentativa anterior. La idea no es reenviar a ciegas la misma solicitud, sino reconstruirla a partir de una premisa válida.

La prohibición del servidor también tiene un alcance preciso. Afecta a esa PushVerification rechazada; no prohíbe todos los reintentos de todas las notificaciones. Una nueva suscripción correctamente vinculada no es equivalente a insistir en enviar la antigua verificación bajo condiciones que ya fallaron.

Para el responsable del producto, la consecuencia es muy práctica. La palabra «suscrito» no basta como evidencia interna si agrupa alta aceptada, código recibido y vinculación verificada con la generación actual. El usuario no necesita ver todos esos pasos. El operador sí necesita saber cuál falta cuando recibe una queja de ausencia de avisos.

Pedir que se reinstale la aplicación puede alterar el estado local, pero por sí solo no demuestra que la ruta de recuperación funcione. Como hipótesis de gestión, conviene comprobar si ese remedio desplaza al cliente el coste de reconstruir algo que el servicio debería poder reconciliar. No se atribuye aquí esa práctica a una empresa concreta.

Una última llamada que no debe darse por garantizada

La sección de rotación de RFC 9749 permite un periodo de transición con las claves antiguas para sus suscripciones correspondientes. Al terminarlo, o inmediatamente si no existe transición, deben destruirse las suscripciones de la clave anterior. El texto también ofrece un último StateChange opcional que supuestamente llevaría a PushSubscription/changes y a descubrir el nuevo estado de sesión.

Esa última cadena es objeto de una objeción técnica. El registro de erratas de RFC Editor muestra la 9055, presentada por Neil Jenkins el 31 de julio de 2026. Propone borrar el párrafo porque PushSubscription no está asociado a una cuenta como requiere la estructura StateChange descrita, y RFC 8620 no define PushSubscription/changes.

Al revisarlo el 7 de septiembre, su estado seguía siendo Reported, no Verified. No corresponde anunciar que el estándar ya ha cambiado ni concluir que todos sus despliegues están rotos. Sí corresponde contrastar las interfaces —que respaldan esas dos observaciones— y no vender el recorrido cuestionado como una garantía de interoperabilidad.

Además, aunque existiera un aviso perfectamente válido, el transporte no garantizaría despertar al cliente. RFC 8030 limita la conservación del mensaje mediante su tiempo de vida, que el servicio puede acortar. Un mensaje con tiempo de vida cero no espera a un dispositivo que no está disponible. «Último aviso» describe la intención del emisor, no una obligación cumplida del receptor.

Por eso debe probarse qué ocurre cuando un cliente dormido vuelve a estar activo sin haber recibido nada. La recuperación no puede depender exclusivamente de un aviso cuya entrega no se asegura. Tampoco la inscripción de la capacidad en IANA certifica ese comportamiento: registra un identificador, no el resultado de pruebas de cada versión instalada.

Recuperar sin ampliar el alcance

La observabilidad tiene sus propios límites. RFC 8620 exige borrar de forma segura la URL y las claves de cifrado al destruir la suscripción, y prohíbe devolverlas mediante PushSubscription/get. Guardar indefinidamente copias completas en los registros de diagnóstico daría una segunda vida a material retirado.

Para investigar la transición pueden bastar identificadores no secretos de generación, marcas temporales limitadas y resultados de verificación. El objetivo es reconstruir la secuencia de decisiones, no conservar todos los secretos que pasaron por ella.

La suscripción también está ligada a las credenciales de API que la crearon. Su revocación o caducidad no debe tratarse como una simple incidencia de transporte. Y un cliente no debería modificar suscripciones cuyo deviceClientId no reconoce como propio. Restaurar un dispositivo no autoriza a destruir los canales de los demás.

Estos límites evitan un falso éxito: que el sistema vuelva a funcionar para una sesión porque una reparación demasiado amplia deshizo el trabajo de otras. Una buena recuperación conserva el perímetro, además de restablecer la actividad.