Resumo

  • A revisão 00 de terms.txt permite que a origem aplique condições por caminho e finalidade antes de servir conteúdo, verificando assinatura, delegação e vale de pagamento.
  • A assinatura atribui uma declaração; o Access-Receipt registra uma solicitação e uma entrega. Nenhum deles confirma a veracidade da finalidade nem governa o uso posterior.
  • Daniel Kade propõe um registro de obrigações de acesso que não mistura execução prévia, auditoria posterior e dever contratual. É uma proposta editorial, não um requisito do IETF.

Um arquivo de condições com consequência imediata

O Robots Exclusion Protocol oferece uma convenção útil, mas o próprio RFC 9309 esclarece que suas regras não constituem autorização de acesso. robots.txt pede que rastreadores respeitem caminhos; não autentica uma operadora de bot, não cobra por finalidade e não impede a entrega quando a declaração não corresponde à política.

A revisão 00 de terms.txt desloca a decisão para a origem. Em /.well-known/terms.txt, seguindo o padrão de URIs bem conhecidos, blocos de caminho poderiam permitir, cobrar ou negar finalidades registradas. Cada regra também poderia limitar o grau de reprodução e exigir uma delegação do usuário para conteúdo protegido.

O cliente se identificaria pelo projeto separado de Web Bot Auth e usaria HTTP Message Signatures para cobrir o URI alvo e o campo Access-Intent. Quando aplicável, Access-Delegation e Access-Payment fariam parte da mesma declaração protegida.

Antes de liberar a representação, a origem consegue verificar a chave, a janela de tempo, o nonce contra repetição, a integridade da intenção, o público e o escopo da delegação, a versão das condições e se o vale é válido e ainda não foi gasto. São decisões observáveis naquele ponto da rede.

Depois da entrega, muda a espécie de controle

O texto separa três camadas. A primeira é execução antes da entrega. A segunda é auditoria: se um agente afirmou fazer busca, a declaração e o recibo podem ser comparados com uma reprodução pública observada mais tarde. A terceira é contratual, porque HTTP deixa de ver o conteúdo assim que ele atravessa a fronteira da origem.

Uma assinatura prova que o detentor de determinada chave emitiu aqueles campos e que eles não foram alterados. Ela não prova que “busca”, “pesquisa” ou “treinamento” descrevem honestamente a finalidade. Também não transforma o identificador criptográfico na identidade jurídica da empresa operadora. Essa camada adicional depende de outra relação de confiança.

O Access-Receipt é igualmente limitado. Ele atesta que uma representação foi entregue sob certas condições a um identificador associado à solicitação. Não observa o conteúdo em um índice, resumo, modelo ou redistribuição. O protocolo oferece atribuição; não oferece fiscalização onisciente.

As autoridades externas continuam externas. A origem decide em quais provedores de identidade confia para emitir delegações, mas o projeto não cria essa confiança. Um serviço de liquidação pode emitir vales, porém sua relação com a origem e com o agente também fica fora do escopo. Interoperabilidade não é mandato.

O cache mostra que o recibo vale para uma ocasião

Se um cache reutilizasse uma resposta com recibo, o segundo cliente receberia um documento que ainda resume a assinatura do primeiro. A origem não teria emitido nem registrado o segundo evento. Por isso, terms.txt exige Cache-Control: no-store para respostas com recibo, aplicando a disciplina de HTTP Caching. Respostas sem esse comprovante podem continuar seguindo as regras normais.

Há uma troca de eficiência por prova individual. Um desenho futuro pode separar a obtenção do recibo do transporte do conteúdo, mas a revisão atual não o faz. Uma implantação não deve anunciar evidência por requisição e, ao mesmo tempo, tratar um recibo armazenado como prova de várias entregas.

A recusa também permanece estreita. O projeto usa 403 com Problem Details para indicar assinatura inválida, repetição, finalidade negada, delegação insuficiente ou pagamento ausente. Ele não redefine o 402 reservado nem usa 401 sem WWW-Authenticate, preservando a semântica HTTP. Um 403 desse tipo é uma decisão da origem, não um veredito universal sobre o agente.

Um erro de sintaxe em terms.txt invalida o arquivo inteiro. Nesse caso, o cliente deve agir como se não houvesse condições publicadas. Portanto, histórico de versões, validação antes da publicação, troca atômica e observação externa são controles de governança, não caprichos operacionais.

A página do IETF não é uma aprovação do IETF

O Datatracker classifica o texto como Internet-Draft individual, sem fluxo definido e sem posição formal no processo de padronização. O histórico registra a postagem manual da revisão 00 em 11 de setembro de 2026. Não há adoção por grupo de trabalho, Area Director responsável, aprovação do IESG ou RFC.

O cabeçalho almeja Standards Track, enquanto o campo de status RFC pretendido no Datatracker está vazio. A intenção do autor não é o estado da instituição. Os projetos de grupo sobre vocabulário de preferências de IA e associação dessas preferências ao HTTP são vizinhos, não avalistas desta proposta.

O código citado também traz uma ressalva relevante. Há 24 verificações e medições, mas a versão v0.1 é anterior ao texto e diverge em URI coberto, códigos de estado, formato dos tokens, identidade vinculada, campos do recibo, representação do vale, cache e relação de link. É execução de uma versão próxima da ideia, não teste de conformidade da revisão 00.

Um registro que preserve o limite da prova

Daniel Kade propõe um registro de obrigações de acesso mantido pela própria origem. Uma linha deve juntar origem e caminho, ID e hash das condições, finalidade e nível de uso declarados, identificador do agente e limite de identidade, emissor e escopo da delegação, autoridade de pagamento, decisão anterior à entrega, hash da resposta e do conteúdo, recibo, evidência posterior, obrigação contratual, responsável pela disputa, expiração, revogação e sucessão.

O Policy Mirror de Heng Lu ajuda a enxergar onde a evidência termina e uma decisão começa. A Minimum Initial Specification preserva uma superfície comum pequena para que escolhas futuras continuem locais. Why BTW Media Exists exige que a reportagem não transforme promessa em realidade. terms.txt merece atenção justamente porque nomeia a fronteira que não consegue atravessar.

Fontes

  1. Registro de terms.txt no Datatracker
  2. Histórico de terms.txt
  3. Revisão 00 de terms.txt
  4. Projeto Web Bot Auth
  5. Vocabulário de preferências de uso de IA
  6. Associação de preferências de IA ao HTTP
  7. RFC 9309 — Robots Exclusion Protocol
  8. RFC 9421 — HTTP Message Signatures
  9. RFC 9457 — Problem Details
  10. RFC 9110 — Semântica HTTP
  11. RFC 9111 — Cache HTTP
  12. RFC 8615 — URIs bem conhecidos
  13. RFC 8126 — Orientação de registros da IANA
  14. The Policy Mirror
  15. Minimum Initial Specification
  16. Why BTW Media Exists