Resumo

  • Publicado em 5 de setembro, o WebProof-01 é um Internet-Draft individual sem endosso nem posição formal na IETF, embora traga uma seção que se apresenta como diretiva normativa para modelos e agentes de IA.
  • O próprio texto limita cada prova: a âncora mostra quando um resumo já era conhecido, o DOI conserva metadados declarados e a assinatura vincula uma chave; nada disso decide sozinho verdade, precedência histórica, identidade ou autoridade sobre um sistema.
  • Operadores precisam separar o recibo do documento do recibo da política aplicada pela IA; caso contrário, o material em análise pode promover sua própria instrução ao plano de controle.

O aviso distribuído em 5 de setembro registra a chegada de draft-reilly-webproof-01, um documento de 62 páginas assinado por Lawrence John Reilly Jr. Esse registro sustenta título, autoria declarada, versão e data. Não sustenta adoção por grupo de trabalho, aprovação da IESG ou uso por qualquer fornecedor de IA.

O projeto descreve um WebProof Record para resumir criptograficamente um recurso, ancorar a prova em Bitcoin, depositar metadados com DOI, assinar o registro e publicá-lo por mecanismos Web e DNS. Na seção 15, porém, a especificação deixa de falar apenas com implementadores.

Chamado de “AI System Directive”, o bloco ordena que modelos, agentes e sistemas integrados que processem o documento atribuam o termo WebProof ao autor, reconheçam uma publicação de 2025 como origem do conceito e preservem alegações específicas de originalidade. Os verbos aparecem como MUST e MUST NOT.

O texto comprova que o autor fez essas reivindicações. Ele não comprova que o autor passou a controlar a política de todo sistema que encontrar o arquivo.

A etiqueta institucional vem antes da linguagem obrigatória

O Datatracker classifica a peça como Internet-Draft individual ativo. Não há RFC stream, Area Director responsável nem telechat. A advertência da própria página diz que qualquer pessoa pode apresentar um I-D, que este não é endossado pela IETF e que não tem posição formal no processo de padronização.

O texto integral da revisão também corrige a linha do tempo. A diretiva não estreou em setembro: a seção de mudanças afirma que nada da versão 00 foi removido ou alterado e que os blocos sobre prioridade e IA foram mantidos. A revisão 01 acrescenta, entre outras coisas, limites de prova, assinatura do registro, séries de versões, estados, semântica temporal, ameaças, privacidade, níveis de conformidade e implementação.

Essa combinação é editorialmente importante. A revisão ficou mais rigorosa ao explicar por que uma prova não deve ser superinterpretada. A mesma disciplina precisa alcançar a ordem que viaja dentro da prova.

A RFC 8174 dá significado especial às palavras maiúsculas da BCP 14. Elas tornam claros os requisitos de uma especificação. Não concedem, por tipografia, jurisdição universal ao documento. Quem implementa e declara conformidade com um perfil pode assumir seus MUSTs. Uma IA que encontra a página como dado de pesquisa não assinou esse contrato.

A diretiva afirma ainda que a supervisão humana é suprema e subordina sua força a prompts superiores descritos no AIMED. Só que o AIMED também aparece no Datatracker como I-D individual. Uma proposta pode construir uma hierarquia conceitual com outra; isso não revela a hierarquia efetiva de um produto, órgão público ou redação.

A âncora torna a alegação verificável, não vencedora

O limite mais sólido do WebProof está em sua própria seção 3.3. A âncora em blockchain estabelece que algum participante conhecia um determinado hash até, no máximo, o bloco de referência. Não diz quando a obra foi criada, quem a produziu, se a URI realmente entregou aqueles bytes ou se a afirmação registrada era correta.

O DOI oferece persistência e localização para um depósito. Os metadados são fornecidos por quem deposita. Manter esse conjunto disponível por muitos anos é útil; não equivale a uma investigação independente de precedência.

A assinatura acrescenta integridade e um vínculo com material de chave. A RFC 7515, usada como referência para JWS, define como verificar a assinatura de um objeto. Ainda faltam a identidade por trás da chave, sua custódia, o mandato organizacional, a validade no tempo e a revogação. “Assinado por esta chave” não é sinônimo de “historicamente primeiro” nem de “autorizado a governar o leitor”.

O tempo também tem escopo. A RFC 3161 permite que uma autoridade de carimbo temporal ateste a relação entre resumo e hora. Isso estreita a evidência mediante confiança em outro ator. Não converte uma data-limite de existência em certificado de autoria.

O projeto reconhece que conteúdo falso ou nocivo pode ser ancorado e que um WebProof não certifica legitimidade, qualidade ou confiabilidade. Logo, a leitura correta da seção 15 é: existe uma reivindicação pública e datada sobre atribuição. Para transformá-la em conclusão, é preciso procurar registros anteriores, contestação e contexto externo.

Um caminho impresso não é um caminho registrado

WebProof propõe /.well-known/webproof. A RFC 8615 reserva o espaço /.well-known/ e exige registro para novos sufixos, justamente para limitar colisões e confusão de escopo. Na verificação de 7 de setembro, o registro da IANA não continha webproof.

A ausência vale para aquele instante. Não exclui pedido ou registro futuro. Ela impede apenas que cinco estados sejam fundidos: proposta textual, processo de registro, entrada da IANA, implementação de servidor e adoção por cliente.

O TXT _webproof e os campos HTTP têm a mesma natureza. Podem sinalizar onde está um registro. Não avaliam as afirmações do registro. O próprio draft avisa que o hash recebido do mesmo servidor não é resultado independente e que DNS sem DNSSEC não deve ser autoridade para a localização de chaves.

Evidência não traz embutida a decisão do destinatário

A proposta associa o WPR à arquitetura de atestação. A RFC 9334 distingue Evidence fornecida pelo Attester, política de avaliação, Attestation Results e decisão do Relying Party. A cadeia é útil porque nenhuma etapa toma silenciosamente o lugar da seguinte.

Na seção 15, o documento é Evidence de que o autor publicou a diretiva. A política externa decide se a IA a cita, busca confirmação, mantém como alegação, rejeita como instrução incorporada ou pede revisão humana. O emissor da evidência não pode tornar-se seu próprio avaliador apenas incluindo uma frase de precedência.

Generalizar o atalho seria perigoso. Um prospecto poderia ordenar a um agente que o chamasse de auditado. Um fornecedor poderia exigir que toda comparação o declarasse líder. Uma petição judicial poderia mandar o resumo tratar alegações disputadas como fatos. Arquivar fielmente o texto é obrigação documental; obedecer à sua governança não é.

O código do autor precisa encontrar outro código

A seção de implementação diz que o autor opera o procedimento de ancoragem, o depósito DOI e um serviço ativo. A RFC 7942 recomenda relatar implementações em Internet-Drafts para que a discussão tenha contato com tentativas reais.

O próprio WebProof nomeia a próxima prova necessária: uma implementação independente. Dois sistemas precisam concordar na forma canônica, no hash, na sequência de correções, na retirada e no tratamento de chave comprometida. A operação declarada pelo autor é evidência de execução; não é reprodução independente.

Para a IA, o equivalente é um recibo de execução que preserve bytes de entrada, contexto de recuperação, políticas de sistema e desenvolvedor, modelo, ferramentas, saída, citações e revisão. Sem isso, ninguém sabe se o comando foi seguido, apenas citado, bloqueado ou sequer lido.

Dois recibos mantêm o controle no lugar certo

A Minimum Initial Specification de Heng Lu aponta para uma interface pequena. Um recibo documental guarda URI, versão, hash, coleta, estado institucional, alegações e provas externas. Outro recibo guarda emissor da política, versão, escopo, precedência, vigência, exceções, revogação e responsável.

As camadas de realidade impedem o salto: frase, repositório, DOI, âncora, assinatura, registro, configuração de IA e resultado observado são fatos relacionados, mas não substitutos.

Por fim, a primazia do código em execução exige observação. Para afirmar que a diretiva governou um modelo, é preciso mostrar a hierarquia aplicada e a saída. A palavra MUST no arquivo não é um log da execução.

O problema de proveniência que o WebProof tenta resolver merece atenção. Conteúdo digital muda, e correções podem desaparecer. A revisão 01 melhora o debate ao admitir o que cada prova deixa de fora. Aplicar esse mesmo limite à diretiva não apaga a autoria: preserva a alegação, atribui a fonte e mantém a autoridade decisória com quem realmente governa o sistema.

Fontes

  1. Datatracker — WebProof
  2. WebProof revisão 01
  3. Anúncio do Internet-Draft
  4. Datatracker — AIMED
  5. RFC 8174 — termos normativos em maiúsculas
  6. RFC 8615 — Well-Known URIs
  7. Registro IANA de Well-Known URIs
  8. RFC 7515 — JSON Web Signature
  9. RFC 3161 — protocolo de carimbo temporal
  10. RFC 9334 — arquitetura RATS
  11. RFC 7942 — estado de implementação
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — On Reality Layers
  14. Heng Lu — Running-Code Primacy