Resumo

  • O draft-deshpande-secevent-http-multi-set-push-03 permanece em IESG Last Call até 23 de setembro de 2026. É um Internet-Draft individual da área de Segurança, com intenção de Proposed Standard, ainda sem aprovação final.
  • Vários Security Event Tokens (SETs) podem seguir no mesmo POST HTTPS. O destinatário identifica cada jti em ack ou setErrs; esses campos comunicam recebimento e validação, não o resultado de uma suspensão ou revogação.
  • Quem depende de alertas entre organizações precisa medir, por evento, a passagem da entrega ao armazenamento, da avaliação local à execução e da execução ao efeito observável.

O último token do lote

Imagine um pacote com seis eventos. Cinco recebem ack; o sexto aparece em setErrs por falha de validação. O sistema que contabiliza apenas o HTTP 202 trataria o conjunto como entregue e perderia a exceção. Mesmo os cinco aceitos ainda podem estar aguardando identificação do usuário e decisão da política local. Esse exemplo é hipotético e não descreve falha conhecida de um operador.

A economia proposta tem base técnica. O RFC 8935 define o envio de um SET por solicitação. Muitos eventos destinados ao mesmo receptor podem produzir excesso de pedidos e pressão sobre limites de taxa. A versão 03 do novo rascunho usa um objeto JSON sets, com cada token associado ao seu jti, e devolve recibos individuais em ack ou erros individuais em setErrs. O Datatracker registrava em 21 de setembro a consulta final do IESG; não há nessa classificação uma decisão de publicação como RFC, prova de adoção ou evidência de uma ação de segurança concluída.

O alcance de ack é deliberadamente estreito. O receptor deve informar o identificador de cada SET recebido em uma das duas categorias. A especificação proíbe usar esse mecanismo para relatar erros além da análise e validação do token. A escolha de associar o sujeito externo a uma conta interna, encerrar uma sessão ou negar acesso pertence a outro processo. Uma resposta bem-sucedida da camada de entrega não pode substituir seu registro.

Há uma complicação temporal. Uma solicitação com sets vazio pode cobrar recibos de tokens anteriores; a resposta de hoje pode mencionar jti de ontem ou de outra chamada. O operador deve conciliar pelo identificador do evento. Depois de um ack, o transmissor não precisa manter o SET para retransmissão; o destinatário fica responsável pela retenção exigida por sua confiabilidade. O protocolo, porém, não fornece uma trilha de auditoria do resultado da política local.

Para um token sem ack nem setErrs em prazo razoável, o transmissor deveria tentar novamente, podendo impor um limite de tentativas. Depois de confirmado ou rejeitado, não pode reenviar o mesmo jti; uma nova tentativa após erro exige novo SET e identificador novo. O receptor pode descartar silenciosamente uma repetição já tratada, mas a proteção contra replay não é obrigatória. O desenho, portanto, não promete execução exatamente uma vez.

A espera para formar lotes também tem limite. O rascunho proíbe atrasar indevidamente eventos sensíveis e recomenda disparar quando se atinge um tamanho ou quando o SET mais antigo espera além de um prazo configurado. O exemplo de um a dois segundos não é garantia universal. O receptor deveria impor limites tanto à quantidade de tokens quanto ao total de bytes, rejeitando integralmente pedidos grandes demais com 413. E o fato de dois eventos viajarem juntos não cria ordem cronológica nem transação para os sistemas de destino.

O RFC 9967 trata de outra fronteira: correlacionar uma solicitação SCIM assíncrona com um evento posterior. O multi-SET trata da entrega agrupada e do recibo por token. Nenhum dos dois prova a decisão de acesso em outro domínio.

Fontes

Estado no IETF; texto da versão 03; RFC 8935; RFC 8417; RFC 9967.