Resumo

  • A resposta 202 de draft-deshpande-secevent-http-multi-set-push-03 pode reconhecer alguns jti, registrar erros de outros em setErrs e citar requisições passadas. O código aceita o envelope, não conclui o lote.
  • O texto é uma submissão individual patrocinada por Area Director, em Last Call até 23 de setembro de 2026. Não há estado de grupo de trabalho, implementação confirmada, aprovação do IESG, RFC ou ação IANA concluída.

Quatro Security Event Tokens viajam no mesmo POST. A resposta é 202, mas seu corpo reconhece três identificadores e rejeita o quarto. Um quinto resultado pode pertencer a uma requisição anterior. Mesmo os eventos reconhecidos ainda podem aguardar a ação do sistema que revoga uma sessão ou altera o estado de uma conta.

Esse quadro é coerente com a revisão 03 de HTTP Push Delivery of Multiple Security Event Tokens. O lote economiza transporte; não cria uma transação. Por isso, tratar a cor verde da requisição como prova coletiva é perder a semântica que o protocolo oferece.

O registro pertence ao jti

O tipo application/secevents+json usa um objeto sets indexado pelo jti de cada token. O receptor valida os membros separadamente. O 202 contém ack obrigatório e pode conter setErrs, também por identificador. O exemplo do rascunho combina confirmações e erro na mesma resposta aceita.

Resultados não precisam pertencer ao POST atual. O receptor pode responder por tokens antigos; o transmissor pode enviar sets vazio para consultar confirmações atrasadas. Uma indicação sobre jti desconhecido deve ser ignorada. A reconciliação precisa seguir o evento, não apenas a chamada HTTP.

Um SET sem resposta é reenviado até receber confirmação, erro específico ou atingir o máximo de tentativas. Políticas locais de tempo e armazenamento podem descartá-lo. O primeiro 202 não informa como essas decisões terminaram.

Entrega não é aplicação

No rascunho, ack cobre recebimento, análise e validação. Não garante efeito posterior. A RFC 8935 separa entrega de processamento; a RFC 8417 descreve o SET como afirmação de fato, não comando. A ação é decisão independente do destinatário.

A RFC 9110 define 202 como aceito para processamento ainda não concluído, que talvez nem ocorra. Multi-SET Push inclui evidência por item nesse envelope deliberadamente aberto, sem alterar HTTP.

Também não há ordem ou atomicidade. Cada SET é independente; a posição não estabelece dependência cronológica; não existem requisitos transacionais. Proximidade no JSON não comprova causalidade.

Processo do IETF sem atalhos semânticos

O Datatracker lista a revisão 03 como Internet-Draft individual ativo na Security Area, destinado a Proposed Standard. A Last Call começou em 26 de agosto e termina em 23 de setembro. O estado de grupo de trabalho é None e não existe telechat marcada.

Segundo o shepherd, SECEVENT já havia terminado e faltava energia para reconstituí-lo. Deb Cooley patrocina a submissão individual. Isso não indica uma rejeição técnica, mas também não equivale a consenso de grupo de trabalho.

A revisão do Security Directorate classificou o texto como Ready, com sugestão menor. Não há implementação confirmada; a intenção de uso no OpenID Shared Signals Framework é apenas intenção. A ação da IANA depende de aprovação futura. Last Call não é aprovação do IESG nem publicação de RFC.

Recibo operacional por evento

Daniel Kade propõe guardar, para cada jti, a requisição original e seu horário, confirmação ou erro exatos, referência a requisição anterior, tentativas, próxima decisão e motivo de descarte. Acrescente versão da configuração do receptor, hora de validação e estado aplicado, rejeitado ou pendente no sistema posterior.

É um desenho editorial de governança, não exigência do IETF. Ele permite agregar indicadores mantendo o caminho até cada evento. O 202 prova aceitação do envelope; apenas a cadeia do jti preserva o que aconteceu depois.

Fontes