Resumo

  • Um Internet-Draft individual de 28 de outubro propõe registrar afirmação, resultado do emissor, regra e referências por digest às provas utilizadas.
  • O verificador deve possuir os itens de prova e aplicar sua própria política. O relatório distingue released, held e refused; o registro inteiro não recebe o selo “verified”.

A planilha não pode ser sua própria testemunha

A organização que produz uma avaliação conhece seus documentos. Também controla a maneira como os reúne e apresenta. Darren Wright propõe um caminho para que o destinatário não dependa dessa arrumação. Seu rascunho no IETF define um “verdict record” que pode carregar uma resposta do emissor e ser examinado por outra parte. É uma submissão individual com intenção Experimental, sem decisão do IETF sobre adoção.

O registro usa JSON canônico e estrito. Nomeia o writer, identifica a afirmação em exame, lista cada evidência com formato e SHA-256 dos bytes exatos, e guarda uma regra e seu resultado em check. Há versões ligadas pelo digest da anterior. A ligação da chave ao emissor e o limite superior do momento em que o registro já existia são estabelecidos pelo contêiner externo. Uma declaração assinada registrada em SCITT, com recibo verificado, é uma forma possível de transportar esse conjunto. O JSON bem formado não faz o trabalho da assinatura.

A auditoria começa quando o receptor abre seus próprios arquivos. Cada entrada que faz uma etapa passar precisa vir de fora do alcance do emissor: um digest calculado a partir dos bytes que o verificador possui, uma assinatura examinada por ele, uma regra reexecutada, ou sua própria política e âncoras de confiança. Uma frase escrita pelo emissor continua sendo uma frase escrita pelo emissor. Ela não pode resolver uma etapa que, sem ela, ficaria inconclusiva. O poder de redigir uma conclusão fica separado do poder de confirmá-la.

O projeto cuida com rigor da lacuna. Se faltar um item citado, o verificador marca a etapa NOT RUN e aponta qual item faltou. Um formato fora da política aceita também interrompe essa verificação. Se a regra for mecânica, ele a executa de novo sobre os valores do corpo; um resultado diferente causa falha. Uma regra chamada judgement admite decisão não mecânica apenas para os tipos que a política própria do verificador permita. Reter um anexo comprometedor não transforma a ausência em aprovação.

Daí vêm quatro estados para o registro. Todas as etapas passam: released. Uma falha: refused. Nenhuma falha, mas uma etapa sem insumo: held. Política inválida do próprio verificador: no verdict. O relatório traz as razões por etapa, o limite temporal e os digests da política e das âncoras usadas. O texto proíbe um adjetivo geral que soe como verdade — “verified”, “valid”, “true”, “trusted”, “correct”, “proven”, “confirmed” ou “OK”. É uma regra de interface tanto quanto uma regra de arquivo. Um selo amplo faria o emissor parecer dono da conclusão e dos critérios para aceitá-la.

Mesmo o estado released indica só o alcance da inspeção: aquele emissor declarou aquele resultado com aquelas provas e regra até aquele momento. A afirmação de fundo permanece sujeita a outra prova. A proposta conserva a utilidade do parecer sem entregar ao parecer a função de juiz universal.

Fontes: rascunho de Wright, estado no IETF, RFC 9943, RFC 8259.