Resumo

  • A revisão 02 transforma o objeto único numa lista de resultados e exige que cada item identifique o método e o emissor por URI.
  • A URI atribui a avaliação, mas não prova autoria, retransmissão sem alteração nem qualidade do método.
  • Decisões automatizadas precisam manter juntos sujeito, método, emissor, publicador, data, estado e evidência; a nota isolada não basta.

Uma pontuação vira autoridade com muita facilidade. Basta aparecer ao lado do nome de um domínio, cercada pela aparência técnica de uma resposta RDAP. A revisão 02 do projeto draft-bertoldi-regext-rdap-reliability-scoring, enviada em 6 de setembro, é relevante porque tenta impedir esse salto antes da primeira implementação conhecida.

O identificador passa de reliabilityScoring para reliabilityAssessment. O objeto único vira a lista reliabilityAssessment_results, adequada a vários emissores e métodos. scoreScheme e scoreIssuer tornam-se obrigatórios; entram a validade, o identificador da avaliação e os estados ativo, em revisão e retirado.

Dizer de quem é não comprova quem assinou

A nova seção de segurança separa identidade, confiança e autenticidade. Identidade é a atribuição escrita. Confiança é a razão pela qual o consumidor aceita o avaliador. Autenticidade é a prova de que a afirmação realmente partiu dele e chegou intacta.

scoreIssuer entrega uma URI global e estável para a primeira função. Não é uma assinatura sobre o conteúdo. A confiança continua fora do protocolo, e uma afirmação assinada foi adiada para trabalho futuro.

Nem o HTTPS resolve sozinho. O RFC 7481 permite autenticar o servidor e proteger a resposta no caminho. Isso mostra qual endpoint entregou aqueles bytes, mas não confirma que um avaliador terceiro citado no JSON seja o autor. Integridade de transporte e correção factual sempre foram camadas diferentes no RDAP.

Três modelos que não devem receber o mesmo peso

O projeto prevê um serviço de avaliação operado pelo próprio avaliador, a republicação por registro, registrador ou outro servidor e a autoavaliação. A estrutura pode ser idêntica; a relação de controle não é.

No serviço direto, o consumidor pode configurar conjuntamente endpoint e emissor. Na republicação, precisa confiar no avaliador e no intermediário, e a resposta não demonstra de forma independente quem fez o quê. Na autoavaliação, a autoria pode ser certa, mas o interesse de apresentar um bom resultado é evidente.

Por isso, o texto não usa o bootstrap do RFC 9224, que encontra servidores com autoridade sobre dados de registro. Também evita um link genérico do servidor autoritativo para o avaliador, pois o apontamento poderia parecer endosso. Descoberta técnica não é confiança delegada.

A unidade operacional não é o número

A ordem dos itens não indica prioridade, autoridade nem atualidade. Uma nota sete só faz sentido dentro do scoreScheme. validUntil encerra a garantia de atualidade do emissor, sem apagar o registro histórico. Estado ausente não significa ativo. Um resultado retirado pode continuar publicado para informar clientes com cache. A ausência de toda a extensão não representa aprovação, reprovação nem falta de avaliação.

O objeto útil reúne sujeito vinculado, método, emissor, endpoint publicador, identificador, data, validade, estado e cópia da evidência. Um painel que guarda apenas scoreValue destrói a parte mais importante do contrato.

Há ainda uma lacuna de identidade do sujeito. Para domínios, ldhName funciona com a consulta já existente. Para registradores, o serviço usa um handle local e só devolve o IANA Registrar ID em publicIds depois da busca. Quem possui apenas esse ID não consegue formar a consulta em banda. O RFC 8521 é citado como possibilidade, e não como solução; registradores de ccTLDs continuam sem regra fechada.

A forma comum não recebe poder de julgamento

Todo método que pretenda publicar resultados no RDAP deverá explicar o risco da divulgação, notificar a parte avaliada, abrir um período de correção ou contestação, minimizar os dados e justificar especificamente uma avaliação no nível de domínio. Uma nota ruim pode ajudar defensores e, ao mesmo tempo, funcionar como mapa de alvos.

O protocolo não escolhe o prazo, o árbitro, a governança nem a consequência de uma contestação. Essa contenção é correta. A camada comum transporta o estado da afirmação; ela não ganha mandato para decidir a sanção.

A revisão reconhece ainda que o resultado é informativo, não uma certificação; que uma nota alta não garante ausência de falhas; e que evidenceUri pode mudar, exigir acesso ou desaparecer. O campo é útil quando permanece evidência de uma afirmação, não quando vira sentença automática.

Fontes

  1. Registro no IETF Datatracker
  2. Projeto RDAP, revisão 02
  3. Projeto RDAP, revisão 01
  4. RFC 7480
  5. RFC 7481
  6. RFC 8521
  7. RFC 9082
  8. RFC 9083
  9. RFC 9224
  10. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  12. Running-Code Primacy