A troca terminou. A assinatura ainda espera.

Resumo

• Uma mudança de chave entre a consulta à Session e a criação da assinatura pode causar rejeição da verificação. O servidor não deve repetir essa verificação; o cliente precisa conferir o sessionState devolvido.
• A errata técnica 9055 questiona o aviso final opcional descrito na RFC 9749. Consultada em setembro de 2026, continuava com status Reported: não equivale a uma alteração já confirmada do padrão.

Há uma forma de encerrar uma mudança e deixar seu custo em aberto: considerar concluído tudo o que ocorre no servidor, enquanto o cliente continua esperando uma etapa que não vai se repetir. O chamado fica verde. A continuidade do serviço, não necessariamente.

A RFC 9749, publicada em março de 2025, oferece um exemplo delimitado dessa situação. Ao introduzir a autenticação VAPID no Web Push do JMAP, o documento trata de uma corrida entre a leitura da chave pública e a criação da assinatura de notificações. Se a chave mudar nesse intervalo, a verificação pode ser recusada. O servidor não deve tentar de novo aquela PushVerification.

Isso não é um relato de pane em uma empresa. As fontes examinadas não identificam um fornecedor afetado, uma taxa de falha nem mensagens de correio perdidas. Elas permitem, porém, formular uma pergunta operacional difícil de contornar: quando o emissor não pode repetir a etapa, quem demonstra que o destinatário sabe reiniciar o processo?

A validade de uma informação pode acabar durante o uso

O cliente aprende a chave pública do servidor de aplicação por meio do objeto Session. Em seguida, utiliza um endpoint de push associado àquela chave para registrar a assinatura no JMAP. A consulta e o registro não fazem parte de uma única operação indivisível.

Se o servidor girar a chave nesse intervalo, a verificação poderá ser autenticada com a nova chave, embora o endpoint permaneça vinculado à antiga. A resposta 403 descrita na RFC sinaliza a incompatibilidade entre essas duas referências temporais. Não se resolve necessariamente calculando outra vez a mesma assinatura criptográfica.

A regra de vinculação tem uma finalidade. Segundo a RFC 8292, uma assinatura de push restrita exige autenticação com a chave privada correspondente à chave pública informada na criação. Aceitar qualquer chave que o remetente anuncie como atual eliminaria a restrição. A substituição da chave pública requer uma nova assinatura de notificações.

Mas o código 403 não identifica sozinho essa corrida. Assinatura criptográfica inválida, audiência incorreta e problemas de expiração do token também podem provocar rejeição. É preciso relacionar o momento da criação, a geração da chave e o estado da sessão. Reconstruir todas as assinaturas a cada 403 pode produzir atividade sem produzir diagnóstico.

Outro cuidado é não tratar todas as chaves como equivalentes. VAPID autentica o servidor de aplicação; a proteção do conteúdo depende de criptografia com outra finalidade. O material privado usado na assinatura criptográfica deve ser diferente daquele usado na troca de chaves para cifrar o conteúdo. Identidade autenticada não prova entrega, leitura ou ação do usuário.

O que a resposta de criação ainda não prova

A RFC 8620 exige uma verificação inicial: o cliente deve devolver corretamente o código enviado ao endereço informado antes que o servidor faça as solicitações seguintes. Portanto, uma criação aceita e um canal verificado são resultados distintos.

Essa diferença pede uma leitura cuidadosa da API. PushSubscription/set não possui ifInState, nem retorna oldState e newState. Não se pode importar automaticamente o controle de concorrência de uma coleção comum. O sessionState relevante aparece na resposta externa da API e informa o estado atual do objeto Session.

A RFC 9749 exige que o cliente confira essa informação em relação à applicationServerKey esperada. Quando há divergência, ele pode tentar criar novamente a assinatura e pode destruir a tentativa anterior que não se completou. O objetivo é reconstruir a relação a partir da informação atual, não repetir indefinidamente um pedido baseado na chave antiga.

Também é importante limitar corretamente a proibição de repetição. Ela se refere à verificação recusada nesse cenário, não a toda e qualquer mensagem push. Refazer uma assinatura válida pelo lado do cliente não é a mesma coisa que insistir, pelo lado do servidor, na verificação já rejeitada.

Isso tem consequência para o vocabulário do produto. Uma métrica chamada “assinaturas ativas” perde utilidade se mistura solicitações aceitas, códigos recebidos e relações efetivamente verificadas. O usuário não precisa acompanhar cada estado interno. Quem atende uma falha de notificação, sim, precisa saber onde o percurso parou.

Mandar reinstalar o aplicativo pode modificar o estado local, mas não comprova que a recuperação prevista funciona. Como cenário de avaliação, vale perguntar se a medida apenas obriga o usuário a pagar o custo de uma reconstrução que deveria ser observável pelo serviço. Não há aqui evidência para atribuir esse comportamento a um fornecedor específico.

O último aviso tem dois limites

A RFC 9749 permite um período de transição no qual assinaturas antigas continuam recebendo mensagens autenticadas com a chave correspondente. Ao final dele, ou imediatamente se não houver transição, o servidor deve destruir as assinaturas da chave anterior. Não existe uma duração obrigatória universal.

O texto original acrescenta um StateChange final opcional, que levaria o cliente a chamar PushSubscription/changes e descobrir a nova Session. Essa sequência não deve ser incorporada a um plano como se fosse uma garantia comprovada.

A errata 9055, no registro de RFC Editor, foi relatada por Neil Jenkins em 31 de julho de 2026 e propõe eliminar o parágrafo. A justificativa aponta que PushSubscription não está associado a uma conta compatível com a estrutura StateChange descrita e que a RFC 8620 não define PushSubscription/changes.

Na consulta de 7 de setembro, o status continuava Reported, e não Verified. É uma objeção técnica registrada, não um novo texto normativo já incorporado. As duas observações de interface podem ser conferidas no padrão-base. Isso basta para recomendar cautela com a sequência contestada, mas não para declarar todos os produtos incompatíveis ou anunciar uma pane generalizada.

O segundo limite existiria mesmo com um aviso tecnicamente válido. A RFC 8030 estabelece um prazo de retenção para a mensagem, que o serviço de push pode encurtar. Com tempo de vida zero, a mensagem não aguarda um dispositivo indisponível. Chamar algo de “último aviso” não cria uma obrigação cumprida de recebimento.

O teste necessário é, assim, a volta do cliente que estava inativo e não viu aviso algum. Ele consegue descobrir a alteração e reconstruir uma assinatura verificada? A presença da capacidade no registro JMAP da IANA não responde: o registro coordena o identificador, não certifica o comportamento das versões em uso.

Não recriar o segredo dentro do diagnóstico

Uma investigação pode acompanhar geração de chave, horário da tentativa, conclusão da verificação e retirada. Não precisa guardar para sempre a URL completa de push nem segredos de criptografia.

A RFC 8620 exige apagamento seguro desses valores quando a assinatura é destruída. PushSubscription/get não deve devolvê-los, mesmo quando solicitados. Identificadores não secretos de geração e registros temporais com retenção limitada podem preservar a sequência operacional sem prolongar a vida de material retirado.

As credenciais de API que criaram a assinatura também delimitam sua existência. Revogação e expiração não devem ser reduzidas a uma falha de transporte. Da mesma forma, o cliente não deveria alterar assinaturas cujo deviceClientId não reconhece como seu.

Apagar todas as assinaturas de uma conta para reparar um aparelho pode criar um sucesso local à custa dos outros. O limite de atuação faz parte da qualidade da recuperação. Uma rotina corretiva não ganha autorização para ampliar seu alcance apenas porque tenta restabelecer o serviço.