Resumo

  • O draft-mih-agent-evidence-request-00, de Steven Mih, é um Internet-Draft individual de 26 de setembro, com intenção informativa. Não representa adoção pela IETF, obrigação de divulgar dados ou operação comprovada.
  • A proposta impõe invariância do artefato para o mesmo assunto, ponto de cobertura resolvido e derivação. Um expected_pin guardado fora da custódia do respondente permite cotejar públicos com mais rigor do que um simples limite de frescor.
  • A entrega de prova, a recusa assinada e a ausência registrada após a espera são desfechos diferentes. Silêncio anotado por quem perguntou não é uma recusa assinada por quem deveria responder.

O detalhe decisivo aparece antes da resposta: quem escolhe o ponto a partir do qual se pede o histórico? Se duas equipes confiam apenas na indicação de que a prova é «recente», o custodiante pode selecionar referências diferentes para cada uma. Seus arquivos distintos não demonstram, por si sós, que alguém recebeu uma versão fabricada. Quando ambas trazem o mesmo ponto independente, porém, a comparação fica mais forte. É nesse caso que a nova proposta de Steven Mih exige o mesmo artefato, byte por byte, para a consulta equivalente. O cenário de duas equipes é hipotético, não notícia de uma falha ocorrida.

O Datatracker marca o texto como «Individual» e «I-D Exists», datado de 26 de setembro de 2026. A publicação de um rascunho individual não é consenso da IETF, padronização concluída ou evidência de uso em produção. Seu objeto é a forma de solicitar evidência verificável a uma contraparte, não um formato obrigatório da evidência, um regime de identidade ou um direito de acesso.

O pedido aponta um assunto: histórico inteiro, checkpoints, um registro, intervalo, correlação ou troca entre partes. Em seguida, escolhe exatamente uma forma de cobertura. Com expected_pin, informa um checkpoint já conhecido independentemente. Com min_freshness, estipula uma exigência de atualidade e deixa ao respondente a resolução para um ponto aceitável. Duas opções ao mesmo tempo, ou nenhuma, tornam o pedido malformado. A derivação desejada, quando presente, também delimita qual resposta pode ser comparada.

A invariância não ignora controle de acesso. O respondente pode decidir se atenderá determinada pessoa; quando fornece um artefato para assunto, ponto resolvido e derivação iguais, não pode alterar seus bytes por causa do solicitante ou do canal. Isso restringe a apresentação seletiva de respostas já concedidas. Não obriga a servir todo mundo. Um operador poderia negar uma consulta a um auditor e atendê-la para outro sem violar a exigência de igualdade entre os artefatos efetivamente entregues. A distribuição de recusas, portanto, faz parte do exame.

Há ainda uma segunda forma de selecionar a realidade exibida. Os pontos publicados de um mesmo fluxo devem integrar um histórico de apenas acréscimos, mutuamente consistente. Se cada público guardar uma ponta diferente, comparar apenas o arquivo recebido em cada ponta não basta para perceber uma bifurcação. É preciso manter cópias externas desses pontos e pedir provas de consistência entre eles. Tampouco uma cadeia coerente garante que todo ato real entrou no diário: um evento omitido antes do registro pode deixar uma história perfeitamente consistente, mas incompleta.

O rascunho distingue três resultados terminais. A recusa assinada vincula o resumo do pedido, horário e um motivo legível por máquina à assinatura do respondente. Um motivo genérico de política pode evitar revelar se o assunto existe. A ausência registrada surge quando o prazo de espera passa sem resultado final: ela é anotada pelo solicitante e não explica a causa do silêncio. Um compromisso de retenção adicional e assinado pode tornar uma falta posterior atribuível dentro de sua vigência; nem assim assegura disponibilidade da rede. Mesmo a derivação history_card/1, sem conteúdo dos registros, pode revelar ritmo e volume de checkpoints. Verificabilidade, completude e privacidade são verificações separadas.

Fontes