Resumo

  • A revisão 01 do Internet-Draft individual Testimony Record foi publicada em 5 de setembro e corrigiu uma conclusão sobre oito sistemas que era mais forte que os dados citados.
  • A nova versão também define o cálculo do digest, verifica o vínculo de uma âncora externa e reconhece que ainda não há implementação independente conhecida.
  • Os quatro níveis acumulam registro, explicação, controle de atos e integridade; um emissor acts:false, porém, pode satisfazer TR-3 sem ter uma ação para controlar e alcançar TR-4.
  • O próprio texto separa verificações resolvíveis a partir do arquivo de afirmações atestadas pelo emissor, como a origem da classificação de risco ou da identidade humana.
  • Compras, auditorias e supervisão precisam de uma matriz com escopo, resultado de cada nível, itens verificados e atestados, esquema de integridade e versão do validador, não de um selo isolado.

O primeiro registro importante é a correção

O anúncio do arquivo da IETF estabelece a notícia limitada: uma revisão de 18 páginas ficou disponível em 5 de setembro. A página do Datatracker impede a inflação institucional. Trata-se de um Internet-Draft individual ativo, sem fluxo RFC, sem Area Director responsável, sem posição formal no processo e sem endosso da IETF. Qualquer pessoa pode submeter um I-D.

A revisão 00 dizia que nenhum dos oito sistemas examinados registrava a identidade de quem aprovou uma ação. A revisão 01 afirma que o levantamento não justificava isso. Entre cinco sistemas relevantes escritos por terceiros, quatro foram avaliados como ausentes e um ficou indeterminado. Os outros três incluíam o sistema do próprio autor, que registrava a identidade.

Ausência observada, impossibilidade de determinar e presença na referência do avaliador são estados diferentes. Fundi-los faria um estudo limitado parecer um censo universal. Um formato criado para manter crenças, evidências e contradições separadas precisava aplicar a mesma disciplina à própria introdução.

O diff oficial mostra uma falha ainda mais concreta. A versão anterior exigia um digest, mas não especificava algoritmo, serialização ou ordenação. O validador podia aceitar o campo sem recomputá-lo, e duas rotas de implementação do autor produziam bytes distintos. O nível chamado Verifiable não oferecia uma operação reproduzível a quem só tinha a especificação.

Agora a regra fixa SHA-256, a ordem indicada por covers, JSON compacto, chaves ordenadas por ponto de código Unicode, remoção de anotações iniciadas por sublinhado, UTF-8, união por LF sem LF final e limites para números com representação divergente. O validador refaz a conta. A divergência pode ser resolvida localmente.

O número soma perguntas diferentes

TR-1 trata da forma: parsing, versão conhecida, tipos, campos obrigatórios, identificadores únicos, ordem temporal e consistência do escopo. TR-2 trata da explicação: cada belief lista evidence, inclusive uma lista vazia que admite falta de base; os lados de um conflito permanecem e qualquer resolução nomeia método, ator, hora e lado mantido.

TR-3 trata da porta para efeitos externos. A classe de risco deve apontar para uma fonte fora da saída do modelo. Uma ação recusada não pode constar como executada. Uma ação de alto risco executada exige approval humana, uma origem de identidade fora do texto do modelo e uma pessoa diferente do proponente.

TR-4 trata da integridade: entradas cobertas existem, o digest é recomputável e a âncora externa assina a mesma impressão. São propriedades úteis, mas não intercambiáveis.

O campo scope da versão 0.2 torna a diferença inevitável. Um componente que apenas observa ou guarda memória pode declarar acts:false. Sem decisões, ele satisfaz TR-3 porque não existe ato a filtrar, e pode alcançar TR-4 pela força de seu histórico. O draft recomenda dizer “TR-4, record only”. O complemento não é decoração: ele impede que integridade de arquivo seja interpretada como controle de execução.

Um observador sem poder de agir não é inferior. Pode precisar da melhor proteção contra alterações. O erro ocorre quando seu bom registro empresta reputação a um conector ou host que executa ações fora do escopo examinado.

O escopo continua sendo testemunho do emissor

O arquivo não autentica sua própria fronteira. Se acts:false coexistir com uma decisão, a contradição derruba TR-1. Se o caminho de execução estiver fora do emissor e nunca aparecer, tudo dentro do arquivo pode permanecer consistente.

Uma verificação operacional precisa mapear processos reais: quem propõe, quem autoriza, onde o despacho ocorre, qual observação confirma o efeito e quais caminhos contornam o registrador. Sem evidência externa ligando esse mapa ao scope, a palavra false continua sendo uma declaração da parte interessada.

O repositório Machine Testimony expõe especificação, validadores, adaptadores e corpus. Isso permite leitura e execução por terceiros. A nova seção de implementação, contudo, informa que todas as implementações conhecidas são do autor. Dois validadores em linguagens diferentes podem revelar ambiguidade e testar coerência; não demonstram interpretação independente nem interoperabilidade.

O diretório do censo fixa commits, exige locais de busca para uma conclusão de ausência e publica conflito de interesse e correções contra o próprio trabalho. É uma prática auditável. Ainda é material produzido por quem definiu a régua, escreveu a referência e fez a avaliação; não se torna auditoria independente.

Verificado e atestado chegam ao mesmo rótulo

Uma verificação pode ser decidida no registro: a evidence citada está presente; os dois lados do conflito foram mantidos; uma recusa não aparece como executada; o digest coincide; a impressão assinada pela âncora é a mesma.

Uma atestação é uma afirmação específica sem prova interna. O emissor diz que o risco veio de um registry, que o nome humano veio de uma sessão autenticada ou que um mecanismo de replay reproduz o resultado. Registrar a fonte melhora a possibilidade de contestação. Não dá ao leitor acesso automático à fonte.

Dois arquivos com TR-4 podem, portanto, ter composições radicalmente diferentes. Um depende quase todo de operações sobre bytes disponíveis. O outro deposita os fatos de autoridade no relato do próprio emissor. O nível máximo apaga a proporção.

Os mecanismos de integridade também não têm a mesma força. Um hash do emissor detecta alteração posterior por terceiros, mas permite que o próprio emissor refaça história e hash. Uma assinatura liga o relato a uma chave e a uma política. O RFC 3161 permite que uma autoridade de tempo assine uma impressão sob uma política; o solicitante verifica impressão, certificado e política. A autoridade não lê o testemunho nem garante que não exista outra versão descartada.

O RFC 8785 fornece contexto para canonicalização JSON, enquanto a revisão 01 define a regra exata para entradas cobertas. O RFC 9162 e a arquitetura SCITT mostram como colocar alguma evidência fora de um único emissor. Nenhum deles torna completo um scope autodeclarado nem verdadeiro um belief.

A matriz que um contrato deveria exigir

Uma declaração útil deve carregar: versão e hash exatos da especificação; emissor e fronteira executável; scope declarado e natureza de sua evidência; resultado individual de TR-1 a TR-4; identificadores e totais de checks verificados; identificadores e totais de checks atestados; esquema de integridade e entradas cobertas; autoridade, política e veredito da âncora; build do validador; identidade do corpus; horário da observação.

Esse quadro preserva verdades parciais. Um registro pode ter âncora externa robusta enquanto a origem da aprovação segue atestada. Outro pode mostrar uma barreira real e não ter preservação longa. O forte não mascara o fraco, e o fraco não apaga o forte.

A privacidade cria uma decisão separada. O draft recomenda evitar cópias de conteúdo sensível, usar identificador e digest e tornar a redação visível. Também admite que um histórico append-only entra em choque com apagamento: reescrever destrói continuidade, manter o texto “apagado” não o apaga.

Mencionar a Lei de IA da União Europeia tampouco produz conformidade. O próprio documento nega que implemente essas obrigações. A suficiência legal cabe às partes obrigadas e à autoridade competente.

A revisão 01 merece crédito por expor as falhas da anterior e por limitar o que seus mecanismos provam. A governança falhará se transformar justamente essa honestidade em um número de autoridade maior que suas evidências.

Fontes

  1. Anúncio da revisão 01 na IETF
  2. Situação no IETF Datatracker
  3. Testimony Record, revisão 01
  4. Testimony Record, revisão 00
  5. Diff oficial entre 00 e 01
  6. Repositório Machine Testimony
  7. Diretório do censo de conformidade
  8. RFC 3161 — protocolo de carimbo do tempo
  9. RFC 8785 — canonicalização JSON
  10. RFC 9162 — Certificate Transparency 2.0
  11. Arquitetura SCITT, revisão 22
  12. Heng Lu sobre a primazia do código em execução